Front page | perl.perl5.porters |
Postings from June 2009
RE: Perl 5.10.1
Thread Previous
|
Thread Next
From:
Jan Dubois
Date:
June 30, 2009 22:43
Subject:
RE: Perl 5.10.1
Message ID:
01d201c9fa0e$d204dcf0$760e96d0$@com
On Tue, 30 Jun 2009, Marvin Humphrey wrote:
> On Tue, Jun 30, 2009 at 11:10:20AM -0700, Jan Dubois wrote:
> > Given the way the whole toolchain works,
>
> I don't think it's the "whole toolchain" at issue. CPAN mirrors can
> handle multiple versions of the same distro just fine; it's the local
> install where you get collisions. Kurila could implement my
> suggestion, yet still pull down module distros from CPAN repositories.
It is not just the local installation, it is also the language itself
that has the assumption about immutable interfaces built in:
use MyModule 2.3;
This means that version 2.3 or *any* later version of the module will be
fine. There is no way to tell that MyModule 3 is not acceptable.
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.
> > module names should be treated as an _interface_ promise, and not
> > just a generic human readable tag.
>
> So sometime in the future, we'll get not only Lucy => Lucy2, but LucyX
> => LucyX2. Gross. :(
I agree. 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.
> 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.
> > If you do this properly, then you can even load both MyModule1 and
> > MyModule2 into the same Perl interpreter, something you simply
> > cannot do with just version numbers that don't become part of
> > package names.
>
> 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. 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.
Cheers,
-Jan
Thread Previous
|
Thread Next