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

Re: mauve::reftype()

Thread Previous | Thread Next
From:
demerphq
Date:
August 30, 2010 03:02
Subject:
Re: mauve::reftype()
Message ID:
AANLkTinY0kGiTXZpahi_ApoXeqd2VCwEVRupEUXywpWb@mail.gmail.com
On 30 August 2010 11:36, Nicholas Clark <nick@ccl4.org> wrote:
> On Mon, Aug 30, 2010 at 10:10:13AM +0200, demerphq wrote:
>> On 30 August 2010 09:42, Nicholas Clark <nick@ccl4.org> wrote:
>
>> > 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.
>
> Aha yes:
>
>> For instance we have the "utf8::" namespace, we have the "re::" namespace,
>> we have several tied hash implementations, etc.
>
>
> utf8. The pain
>
> 1: A pragma.
> 2: A namespace with visible functions. (Most of which certainly aren't good
>   practice these days, and some of which never were)
> 3: A namespace used by the internals of the regexp engine.
>
> re.
>
> 1: A pragma
> 2: A namespace with visible functions
>
> That's wrong too.

If its wrong, what went wrong? Whats the failure case? What problem
have we had with these routines and this approach?

> UNIVERSAL.
>
>    has to be builtin
>
> version.
>
>    has to be builtin if we want the core to compare version objects
>
> Tie::Hash::NamedCapture
>
>    supplies the interface to objects returned by the regexp engine
>    autorequired in gv.c
>
> Errno
>
>    supplies the interface to %!.
>    autorequired in gv.c
>
> wait, that's not in universal.c
>
> which means that Tie::Hash::NamedCapture could move to ext :-)

lol.

> which leaves Internals and PerlIO
>
> And I'm not sure that PerlIO::get_layers being there is the best idea
> either.

Could it be that it has to be?

>> 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.
>
> including nothing to do with fixing the problems?

Assume there was a "... unless I really really have to". That was not
intended to be said in the tone of "or ill take my ball home", more in
the tone of "please please guys lets not go there if we dont have to".

> And I don't remember you raising this issue before.

Maybe it wasn't as obvious to me then as it is now that we have had it
around for a while.

Also, I think there are cases where 'use feature' and version level
triggered features are the least worst option. But I dont think they
should be lightly used. If there is a simpler, cleaner way to add
stuff then why not exploit it.

All of the lowercase single word namespaces are reserved for the core
dev team. Why is it such a big deal to exploit them to contain new
keywords in a clean, backwards-compatible possible, but forward
looking way?

I mean, its fine to add smartmatch as new syntax, or add new semantics
entirely using features. That makes sense. Id have no problem with a
feature enabled class syntax for instance. But for new utility subs
IMO its a big hammer with a lot of issues that are just unnecessary.

>> 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.
>
> Or, alternatively, the interface to feature needs to change slightly.
>
> if "use feature XYZ" tries
>
> first: see if it can do it natively
> fallback: require feature::XYZ
>
> then we have a way for 'use feature' to provide backcompatibility too,
> with backcompat modules going into subnamespaces of feature

This sounds like an interesting mechanism. Is it supportable by an
older perl adding a -Mfeature?

>> 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.
>
> why is "use feature" more ugly than "use mauve"?

Because 'use mauve' is optional on new perls. On a new perl I can just
say "mauve::reftype" and not worry about loading a feature.

Whereas "use feature" requires me to do something additional. Why
bother putting it in core at all if you /have/ to load something
additional both old and new? It defeats the whole purpose.

>> This is a ridiculous state of affairs and I'm sorry to say, isnt an
>> improvement at all.
>
> Because I don't agree with your specific previous statement, I don't agree
> with you on this.

Well ok, I went too far there with the hyperbole.

>> 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.
>
> Then I don't see why the code shouldn't be in a module in ext/ (or dual/)
> and imported just like anything else.

If we have to 'use feature' to enable it then yeah I agree.

> The *reason* for feature is that people seem to be arguing that it should be
> a "built in".

No, the reason for feature is because people seem to be arguing that
it should be a "built in" as a "keyword".

But it can be exactly what it is now, built in, and not a keyword.

>> > 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.
>
> I don't agree.
>
> Because if we charge forward, when a better solution could quickly be
> implemented, we create more clutter that could be avoided, which will end up
> sticking around forever.
>
> (which, arguably means at the moment, I'm happy enough with s/mauve/CORE/
> as it's not creating a new namespace)

Ok. noted.

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