Front page | perl.perl5.porters |
Postings from August 2010
From: Zsbán Ambrus
August 30, 2010 01:39
Message ID: AANLkTinJaXrUK05XDC+sQKjkxiTBwXejJsCf1bQaDCtP@mail.gmail.com
On Mon, Aug 30, 2010 at 9:42 AM, Nicholas Clark <firstname.lastname@example.org> wrote:
>> On Sun, Aug 29, 2010 at 6:57 PM, demerphq <email@example.com> wrote:
>> More generally, I question the benefit (wisdom) of jamming things into
>> universal.c. Why not fix Scalar::Util? Why not make them proper
>> keywords protected by 'feature'?
> We weren't convinced that it was viable to change the behaviour of
> well used Scalar::Util functions this late in the game.
That's no reason for making it a keyword. You could just make another
module eg. Scalar::Util::Mauve, or a new import option for
On Mon, Aug 30, 2010 at 10:16 AM, demerphq <firstname.lastname@example.org> wrote:
> The feature idea is broken. Completely broken.
> Show me how you would provide a backwards compatibility layer for a
> feature, and show me how code would be written so it worked fine in a
> new perl and an old perl.
I wonder, what was wrong with introducing new keywords as a "weak
keyword" like lock, instead of as a feature. Then there can be a
compatibility module that would do nothing if the keyword is
available, but imports a function if it's not available.
This, of course, only make sense when a function is expected to be
used so often as say is, so it makes sense to make it a keyword so
it's available without extra use statements and with special syntax.
If you don't need that, then just having the function in a module
distributed with the core is fine. I'm not saying anything here about
whether these functions (blessed, refaddr etc) qualify.