Front page | perl.perl5.porters |
Postings from September 2010
September 9, 2010 11:58
Message ID: AANLkTimqscFDnyjsQFCKSEdpthEH=Lr7s47RmWmvmmKH@mail.gmail.com
On 31 August 2010 13:40, Steffen Mueller <firstname.lastname@example.org> wrote:
> David Cantrell wrote:
>> It's not as if:
>> * 'use lib' happens a lot, so the performance hit is unimportant;
>> * users have complained about having to use Scalar::Util
>> and wouldn't complain about having to 'use mauve' instead
> I'm sorry to be blunt, but you're missing the point.
> a) "use lib" may happen before loading Scalar::Util. I.e. you might want to
> pick up an S::U from ==> "over there" instead of the core one. You know. An
> updated one from CPAN in your private library. This isn't entirely bonkers.
> We want lib.pm to be slim. More so when it comes to loading extra XS.
> b) You don't "use mauve". You just say "mauve::refaddr()".
> The idea in the context (and see my recent mail for my current opinion on
> it) is that you have something like "scalar::refaddr" as a builtin feature.
> The namespace simply serves as a way to prevent clashes with user functions
> (and also some grouping of related functions).
> The reason "mauve" isn't "Scalar::Util" is simply because the "mauve"
> functions aren't doing the same thing.
This is a very succinct summary. Thanks.
With one exception, I did do the goo to support
use mauve qw(refaddr);
but that was just to save people some typing if they use it a lot, and
also to provide a way that people that are concerned about backwards
compatibility could use a CPAN equivalent for older code, (which would
basically be a no-op in a modern perl). Doing so would be strictly
optional in a newer perl.
perl -Mre=debug -e "/just|another|perl|hacker/"