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

Re: mauve::reftype()

Thread Previous | Thread Next
From:
demerphq
Date:
August 30, 2010 01:16
Subject:
Re: mauve::reftype()
Message ID:
AANLkTinDnC2Yuu_FGSKt4vdySPXUyJ1HPKdCdH4A7PgJ@mail.gmail.com
On 30 August 2010 03:58, David Golden <xdaveg@gmail.com> 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.

A plausable one has the distinct disadvantage of being a lousy search
target if it does have to change.

"mauve" has the distinct advantage of being unique in our codebase.

> Without supporting the idea itself, I mildly prefer "scalar" because I
> associate such functions with Scalar::Util already, though I have
> slight reservations about "scalar" because of autobox and confusion
> (overlap?) with SCALAR.
>
> 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'?

See my other mail. Short answer a), the routines dont behave the same
as they do in Scalar::Util, b) feature makes it extremely difficult to
provide a backwards compatible equivalency layer.


> Adding new universal namespaces seems like just another kludgy way of
> enhancing the core without breaking backwards compatibility and we
> already have the feature kludge for that.

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.

When you stare at the mess you have to write you will understand why
"use feature" as an idea is a bad idea to be used /only/ when no other
approach makes sense.

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

The whole idea is so that they are available without having to use a
module. But that they can also be loaded with a module.

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