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

Re: mauve::reftype()

Thread Previous | Thread Next
David Golden
August 30, 2010 12:19
Re: mauve::reftype()
Message ID:
On Mon, Aug 30, 2010 at 4:16 AM, demerphq <> wrote:
>> 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.

I don't get it.  You seem to want to break things and not break things
at the same time.

Case (a): something importing Scalar::Util::blessed gets run on 5.14.
'blessed' keyword is not feature enabled, so the Scalar::Util::blessed
behavior is preserved.  Nothing breaks, which is the point of feature.

Case (b): something importing Scalar::Util::blessed gets run on 5.14.
The 'blessed' keyword *is* feature enabled, but the import of
'blessed' masks the builtin so the original Scalar::Util semantics are
preserved.  Nothing breaks.

This is what "backwards-compatibile" means -- running *old* code on a
*new* perl doesn't change behavior.

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

That's different.  You want a module that provides a *new* feature on
an *old* perl.  There are any number of ways to do that.  C.f.
warnings::compat as an example.  You could have Scalar::Util::Fixed.
(It could even be included as part of the *existing* Scalar::Util
distribution, right?)  Or it could be done via an import flag to
Scalar::Util.  TIMTOWTDI.

None of what you want to do implies that there needs to be a new,
universally available namespace.

(And as a side note, consider the awful pain of keeping
consistent in blead and working on older Perls -- this can get really,
really messy when you try to emulate compiled-in functionality with a

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

I get that you don't like feature. I don't either.  But that ship has
sailed.  If feature is bad, then let's work to remove it or change it.
 ("use feature::foo" or whatever)  But I don't want a soup of
namespaces as the answer to backcompatibility, either.

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

See my point above about  In retrospect, I think the
*worst* design decision with version objects was to compile the
behavior into core and leave the public API in a module, followed by
the decision to try to provide a compatibility layer for older perls.

[To be clear, I mean nothing personal intended towards John Peacock in
that comment.  Sorry, John, I know you've sweated blood over this and
have done heroics to keep it working, but if we could have a
"do-over", version objects might be at the top of my list.  The
downstream pain for the toolchain has been enormous.]

-- David

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