Dave Storrs <[EMAIL PROTECTED]> writes: > > On Fri, 2 Feb 2001, Garrett Goebel wrote: > > $Foo::VERSION eq 1.00 > | > | $Foo::VERSION eq 2.00 > | | > Bar Baz > \ / > My::Module > > Ideally, it should be perfectly legit to have multiple > versions of a given module on your system, which would > resolve this problem nicely. > > One possible implementation for that would be to introduce > a new special token, __VERSION__. It would work something > like this: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > You want this to work with multiple module versions side by side. We > have a disk namespace where we put every module version in its own > directory, and the user can choose which version is required by > specifying 'use lib'. When a new version comes out, we install it > without touching the existing files - which makes backing out an > upgrade very easy. > > If multiple versions of a module could co-exist in the same program, > e.g. by extending the namespace by the module version number, that > would solve some issues in e.g. mod_perl, or in Storable release x -> > x+1 migration scripts. Yes that is what came mind when I heard the vague references about Larry's plan to support the coexistence of different module versions in Perl6. I was wondering where the corresponding RFC was, but there doesn't appear to be any. I like your idea that all the modules would exist separately, but be available by extending the namespace to incorporate module version numbers. So that if one package explicitly required version 1.0, another 2.0, and the third didn't require an explicit version... They'd get exactly what they needed. The unqualified 'use' would use the highest installed version number. We'd probably need a slight change in semantics to allow one to specify a set/range of acceptable module versions. package Bar; use Foo 1.0 package Baz; use Foo 2.0; package My::Module; use Bar >1.0; use Baz; Garrett
