On Tue, Aug 22, 2006 at 12:37:33AM -0700, Trey Harris wrote:
> I misstated my worry here. In this case, by the same rule that "my Dog
> $foo" gets the right version because the longname is aliased to the
> shortname in the lexical scope of the use, it would work.
>
> What I'm actually concerned about is the case where the Dog CPAN
> distribution includes Poodle.pm. I think that we need Poodle.pm to be
> written like:
>
> use Dog-1.3.4-cpan:JRANDOM;
> class Poodle-1.3.4-cpan:JRANDOM is Dog { ... }
>
> If it's written:
> use Dog;
> class Poodle-1.3.4-cpan:JRANDOM is Dog { ... }
>
> then in a running Perl program that has previously loaded Dog-2.1-*,
> Poodle-1.3.4 will become a subclass of Dog-2.1, which causes any code
> using Poodle-1.3.4 to be unable to protect itself from an unforseen
> upstream dependency change.
This is precisely the problem which unix shared libraries have to face
(so yes, it's a real problem), and which is handled by a combination
of sonames and versioned symbols. It seems to me that there is some
merit in considering similar features here. The essential features
are:
- independent version labels for the interface and implementation, so
you can change the implementation while promising that the external
interface remains the same
- individual symbols can be optionally decoupled from the interface
version of the library that contains them and versioned
independently, so even though the interface version has changed from
X to Y, the linker knows that only function foo has changed; clients
that use only function bar will still find this version acceptable.
Shared libraries make this behaviour optional, with the first being
all that most people use, and the second only being used by people
writing large libraries with complex needs (like glibc).
You can get interface versions with nothing more than a stipulation
that Poodle-1.* will always have the same interface, but everybody has
to understand what this means for it to work. I'm not sure if this is
the right approach here.
It is not clear to me whether it is practical to version individual
symbols in perl6 as it currently stands, but it would appear to be
worthwhile to make sure this is possible.
I suspect that this will largely be a matter of establishing
appropriate conventions about versioning for CPAN modules.
