Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
Thread Previous
|
Thread Next
From:
Marvin Humphrey
Date:
June 30, 2009 21:12
Subject:
Re: Perl 5.10.1
Message ID:
20090701041211.GA3483@rectangular.com
On Tue, Jun 30, 2009 at 11:10:20AM -0700, Jan Dubois wrote:
> > In retrospect, perhaps it would have made sense to fork into new namespaces
> > continually -- KinoSearch1, KinoSearch2, and so on.
> I *strongly* believe that you should be doing this whenever you are
> making incompatible API changes.
Sure, in retrospect, that seems like the least worst option. However, your
advice didn't reach me when it would have mattered, two or three years ago.
> 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.
> 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 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.
Interface promises should be conveyed by the combination of the project name
and the major version number. Software consumers have understood that
convention for decades. The fact that Perl/CPAN doesn't support that
convention is a problem -- it leads to "grumbling" from Nick's buddies, and
confusion and frustration for authors like me who find it difficult to do the
right thing.
> 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.
Marvin Humphrey
Thread Previous
|
Thread Next