On Sun, May 12, 2013 at 2:52 PM, Linda Walsh via RT <perlbug-followup@perl.org> wrote: > In what possible circumstance could it break any > existing application? The warning exists because two functions of the same name might have very different behaviors. Cwd and POSIX have 'getcwd' that do (approximately) the same thing, but they aren't actually exact substitutes. While it might be possible for, say, POSIX to determine that the 'getcwd' in the caller's namespace is actually Cwd::getcwd, there's no way for it to know whether the user actually wanted the actual POSIX getcwd or else Cwd's "POSIX getcwd or reimplementation of it". So it exports, and Perl warns and the user can decide what to do about it. I think it would surprise people for a module to not export something it historically exported because a similarly named function were already present, so I wouldn't go with that approach. I would have no problem at all with having POSIX deprecate it's @EXPORT and use @EXPORT_OK instead and warn if import is called without arguments, (e.g. deprecate and warn in 5.20, and actually remove @EXPORT in 5.22) but I think the odds of that being welcome by p5p are slim at best. That's the Perl philosophy of bending over backwards to avoid breaking old code. I happen to disagree with that philosophy in many cases, but I seem to regularly be in the minority.Thread Previous | Thread Next