Front page | perl.perl5.porters |
Postings from September 2011
On Fri, Sep 02, 2011 at 10:53:56AM +0100, Nicholas Clark wrote:
> > 6. remove 40 functions which simply forward to core perl functions
> > with the same name, for instance chdir(), but avoid errors from
> > being reported when people explicitly import those.
>
> "avoid errors from being reported" means that you're proposing that working
> code such as:
>
> $ ./perl -Ilib -e 'use POSIX "chdir"; chdir('t');'
>
> becomes a runtime error:
>
> $ ./perl -Ilib -e 'use POSIX "chdir"; chdir('t');'
> chdir is not a valid POSIX macro at -e line 1
>
> not even a compiletime error.
Sorry, got this wrong in my testing. I still had 'chdir' in @EXPORT.
> It would cause less breakage to have a compiletime error.
>
> As currently formulated, this is a stupid suggestion.
> I have considered my wording carefully, and I'm sticking to it.
Sorry, yes, I should have phrased that as "if I understand it correctly"
However, it *will* still break things. Not as many, but it will break things,
and at compile time.
As you observed before:
Core builtins (effectively) have prototypes, so enforce particular parameters.
Wrapper functions don't
So by not exporting core builtins one will generate compile time errors
where anyone has used a POSIX wrapper with an array, where the core builtin
expects 2 or more scalars.
$ perl -le 'use POSIX "link"; sub my_link { link @_ }'
would change behaviour to something like this:
$ perl -le 'use POSIX (); sub my_link { link @_ }'
Not enough arguments for link at -e line 1, near "@_ }"
Execution of -e aborted due to compilation errors.
And anyone using them directly, in either way below
$ perl -le 'use POSIX "chdir"; sub my_chdir { POSIX::chdir @_ }'
$ perl -le 'use POSIX (); sub my_chdir { POSIX::chdir @_ }'
would have their code break on them at runtime without the wrapper
implementation.
Yes, this is considerably less than the 40 I had mistakenly assumed.
But it's more than 0. And as there are wrappers that reorder the arguments,
and others that rename the functions, wrappers have to remain, so the
fixed cost of infrastructure for wrappers has to remain.
The refactored POSIX.pm now has the incremental cost of a wrapper being 1
line of code. It's a low cost to keep all the wrappers.
> > 7. remove stuff which no-one in its right mind should use: isalnum,
> > wide character functions.
>
> But people do do this. Moreover, sensible people inherit crazy spaghetti balls
> of code that keep working, where there is no time (or business reason) to
> change the code. This sort of change would punish people.
Both these proposals break working code. Suboptimal code, agree.
"Shouldn't have been written like that" code, agree.
But working code.
Who are we to punish people?
Nicholas Clark
Thread Previous
|
Thread Next