Re: Perl 5.10.1

Front page | perl.perl5.porters | Postings from July 2009

Thread Previous | Thread Next

From:

Marvin Humphrey

Date:

July 1, 2009 20:18

Subject:

Re: Perl 5.10.1

Message ID:

20090702031808.GA20337@rectangular.com

On Tue, Jun 30, 2009 at 10:43:10PM -0700, Jan Dubois wrote:

> This assumption is made in many places, like the META.yml files,
> PREREQ_PM in Makefile.PL, or in the CPAN shell when asked to upgrade
> modules.

From a distance, extending META.yml and PREREQ_PM to deal with explicit ranges
in addition to implied ranges looks doable (*ducks*).   Dunno about the CPAN
shell.  John Peacock has "use" directives under control.  And as mentioned
earlier, CPAN mirrors have zero problems handling multiple versions.  Much of
the toolchain looks like it could either manage multiple versions today or be
adapted to manage them.

I think the real sticking point is actually that it's never going to be
practical in Perl 5 to load two versions of the same module at the same time.
As is so often the case, shared globals are the root of all evil: if you
"load" JSON::XS 1.53 and JSON::XS 2.24, who gets control over the shared
global "JSON::XS" stash?

From what I gather, Perl 6 handles this by aliasing.  "Dog" in the following
example is actually two different packages.

   use Dog:<1.2.1>;
   my Dog $spot .= new("woof");

   use Dog:<2.*>;
   my Dog $spot .= new("woof");

I don't see a good way to fake that up that in Perl 5 -- invoking package
methods via global symbols is too ingrained.

I'd love to be disabused of that notion, though.  :)  

> > So sometime in the future, we'll get not only Lucy => Lucy2, but LucyX
> > => LucyX2. Gross. :(
> 
> On the bright side I can argue that this ugliness will hopefully have some
> restraining effect on module authors to break APIs repeatedly and instead
> just bunch them up.

Deny authors a sane versioning mechanism which allows them to break backwards
compatibility gracefully, and they'll break backwards compatibility anyway --
just not gracefully.  

History has rendered an unkind judgment on the idealistic notion that package
names should define immutable interfaces.  Authors don't like renaming their
products.

> > I agree that given what we have to work with, namespace forking is a
> > workaround that allows you to keep backwards compat promises. But
> > let's not kid ourselves -- jamming version numbers into the module
> > name is an ugly hack that adds noise to what *ought* to be an easy-to-
> > scan human readable tag.
> 
> I don't know; I kind of like having the Apache vs Apache2 namespaces
> to immediately tell which of the APIs the module expects/implements.

The idea of forking into versioned namespaces has been around for a long time,
yet it hasn't caught on.  Why is there no YAML2?  JSON::XS2?  HTML::Parser3?

And why are there so many modules that never reach 1.0 on CPAN?  I submit that
it's because Perl/CPAN doesn't support sane deprecation and versioning.  If
1.0 wasn't "forever", it wouldn't be such a big damn deal.

> > Your response cements in my mind the conviction that major version
> > numbers *should* be part of the namespace in a dynamic language.
> 
> Of course that is then just syntactic sugar over the convention of
> appending an API version to the package name.

By that logic, the fact that you don't have to save "foo.txt" as
"foo.txt-LAST_MODIFIED:2009-07-01" is "just syntactic sugar" -- you're using a
the space reserved for a name to encode auxiliary information.  

> I believe a rather elaborate version of this this is part of the Perl 6
> spec, but I haven't followed its changes lately, and don't think this part
> has been implemented yet.

I think Perl 6 and "only.pm" have things backwards.  Giving users such
explicit control over version loading is a symptom of frustration with module
authors who break backwards compatibility.  Make it practical for authors to
support punctuated equilibrium, and bingo, your problem goes away for at least
some of us.  

Marvin Humphrey

Thread Previous | Thread Next