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.