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

Re: mauve::reftype()

Thread Previous | Thread Next
From:
demerphq
Date:
August 30, 2010 01:10
Subject:
Re: mauve::reftype()
Message ID:
AANLkTimPJu0A-vEFZQaNhcZpousxusPnd9Ko=t=HNXUd@mail.gmail.com
On 30 August 2010 09:42, Nicholas Clark <nick@ccl4.org> wrote:
> On Sun, Aug 29, 2010 at 09:58:40PM -0400, David Golden wrote:
>> On Sun, Aug 29, 2010 at 6:57 PM, demerphq <demerphq@gmail.com> wrote:
>> > I have pushed a patch to add "fixed" versions of reftype, refaddr and
>> > blessed to universal.c, additionally
>> > at jesse's request this includes weaken() (and its relative isweak).
>> >
>> > I used the namespace "mauve" for now.
>> >
>> > I think the namespace should either be 'ref' or 'scalar'.
>>
>> I'm late to the debate, but on the nitpicky issue of namespace, I
>> would have preferred you just picked one instead of a fake one.  A
>> fake one guarantees we have to change it.  A plausible one stands a
>> chance of not changing.
>
> I don't like the use of a built-in namespace for this.
>
> Historically, functions intended for general use have either
>
> 1: have been keywords, and in the core
>
> or
>
> 2: been in namespaces, and loaded via require or use
>   (where that load causes an actual load an initialisation)

This just isn't true.

For instance we have the "utf8::" namespace, we have the "re::" namespace,
we have several tied hash implementations, etc.

All autoloaded by universal.c

>> 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.

Right.

>> After considering it briefly, I think that if "everyone needs them",
>> then they should be keywords under feature.  If not, then they should
>> be in a module and Scalar::Util should just be fixed.  If it varies by
>> function, then split them up accordingly.
>
> This is generally my feeling too. I don't like a "third way" in the middle.

My objection to making them keywords is that they then have to be
"loaded" with a "use feature".

And I think the "use feature" idea is broken, and that we will regret
it, and I don't want to have anything to do with it.

Consider, with the approach I took how does one provide back-compat?
With code that does "use mauve qw(reftype)" one simply has to create
an on-cpan for-back-compat use only module. With code that doesnt all
one has to do is ensure that "-Mmauve" is in ones PERL5OPT.

How does one provide back-compat to a feature?

Presumably one has to put "use feature XYZ" in an eval. If it fails,
one then has to load some module.

So now new code looks ugly so that old code can work with the new code
because the new code is protecting the old code from using it.

This is a ridiculous state of affairs and I'm sorry to say, isnt an
improvement at all.

I really feel like the little kid in the "Emperor wears no clothes".
The feature idea sucks, we should not use it EXCEPT when there is NO
other way to provide new behaviour without breaking old behaviour.

This isnt one of those cases. There is no old behaviour to break.
There might be by making it a keyword. Ergo making it a keyword
complicates what is actually a simple matter for essentially no reason
other than aesthetics. Which is bogus reason to complicate things.

Im really really really against making this a feature when there is no
good reason to.

>> FWIW, I've always thought that blessed and weaken should be core
>> keywords.  The others strike me as more specialized functions that
>> could just live in a fixed Scalar::Util and imported when needed.
>
> However, it also strikes me that we already have a namespace for core keywords,
> %CORE::
>
> So if (at least) all the feature-enabled keywords were also subroutines in
> that namespace, it provides a way to get at them without use 'feature'

If that were the case, and one could export specific keywords out of
core into a namespace then I would be ok with this change being so
implemented.

But its not the case and IMO waiting for it to be the case is worse
than just moving forward.

Cheers,
yves




-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

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