Front page | perl.perl5.porters |
Postings from August 2010
From: David Golden
August 30, 2010 12:19
Message ID: AANLkTinz0UyYwBmrh8NZv2u0r2Tk3HjuBNiagS7qxveY@mail.gmail.com
On Mon, Aug 30, 2010 at 4:16 AM, demerphq <firstname.lastname@example.org> 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
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 verson.pm
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 version.pm. 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.]