Front page | perl.perl5.porters |
Postings from September 2011
* David Golden (xdaveg@gmail.com) [110902 13:23]:
> > Do you imply that 5.15 is already in feature freeze, because it is
> > right after 5.14 anymore?
>
> No. What I meant is that Jesse declares feature-freeze and then
> user-visible change freeze in the blead branch in the months leading
> up to the next stable release. Then after the stable release (e.g.
> 5.14 in May), blead becomes open for more extensive changes (in the
> 5.15.X series). Next Feb or so, 5.15 will go into feature freeze in
> preparation for 5.16.
Counting back from Feb/2012 there must be a moment not too far away
when the user-visible changes get frozen. So, about when?
The whole purpose of this thread was to check with "Core" what would
be the best way to get the changes into 5.16. Where goes what. Still
not completely sure where the consensus will get us.
> > Once we added prototypes to CORE::, but forgot to add them to the
> > same functions in POSIX.pm. Is that a bug or a feature?
> I think prototypes are a design bug.
>
> If POSIX.pm failed to get prototypes when CORE:: got prototypes, I'm
> supporting of fixing that bug. Particularly where the docs say "is
> identical to the builtin", I think we can add the prototypes.
I do code Perl quite a lot, and use prototypes all the time. In all its
poverty, it still automatically points me to mistakes.
So, we do not like prototypes. On the other hand, we can never ever get
rit of them because backwards compatibility is sacred. Then the second
rule of good programming says: be consistent. CORE::exit uses prototypes,
POSIX::exit does not. How horrible will programs break with respect to
how confusing is it for people that there is a difference?
For instance, some company has a crufty script of 3500 lines (cgi.pl)
A new developer has to extend the script. He is not aware of CORE::chdir
so adds a line "use POSIX 'chdir';" to the top of the script. From then
on, ALL uses of chdir in the code are interpreted differently. The chdir
is changed from being interpreted as unary operator into being a function!
Different priority!
But the currect POSIX.pm manual says:
chdir This is identical to Perl's builtin "chdir()" function,
allowing one to change the working (default) directory, see
"chdir" in perlfunc.
again: "identical".
You may not like prototypes. People may disgust prototypes, but we
have them... let them be used consistently!
> I'm on the fence about not actually doing an import, since presumably,
> once imported, one could locally override the POSIX function. E.g.
>
> $ perl -MPOSIX=chdir -wE 'local *POSIX::chdir=sub {die}; chdir "/"'
> Died at -e line 1.
>
> So making the import a no-op isn't the same thing.
Ok, -1 for you on that patch ;-)
--
Regards,
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
Mark@Overmeer.net solutions@overmeer.net
http://Mark.Overmeer.net http://solutions.overmeer.net
Thread Previous
|
Thread Next