develooper Front page | perl.perl5.porters | Postings from August 2010

Re: mauve::reftype()

Thread Previous | Thread Next
From:
Zsbán Ambrus
Date:
August 30, 2010 01:39
Subject:
Re: mauve::reftype()
Message ID:
AANLkTinJaXrUK05XDC+sQKjkxiTBwXejJsCf1bQaDCtP@mail.gmail.com
On Mon, Aug 30, 2010 at 9:42 AM, Nicholas Clark <nick@ccl4.org> wrote:
>> On Sun, Aug 29, 2010 at 6:57 PM, demerphq <demerphq@gmail.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
Scalar::Util.

On Mon, Aug 30, 2010 at 10:16 AM, demerphq <demerphq@gmail.com> 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.

Ambrus

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About