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

Re: mauve::reftype()

Thread Previous | Thread Next
Nicholas Clark
August 30, 2010 02:36
Re: mauve::reftype()
Message ID:
On Mon, Aug 30, 2010 at 10:10:13AM +0200, demerphq wrote:
> On 30 August 2010 09:42, Nicholas Clark <> 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.


1: A pragma
2: A namespace with visible functions

That's wrong too.


    has to be builtin


    has to be builtin if we want the core to compare version objects


    supplies the interface to objects returned by the regexp engine
    autorequired in gv.c


    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 :-)

which leaves Internals and PerlIO

And I'm not sure that PerlIO::get_layers being there is the best idea

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

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

> 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

> 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"?

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

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

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

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

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About