If the idea of having an author attribute is to allow multiple implementations of a module, why not add an API version attribute? The idea would be to detach the module version number from the module API version number.
This way, if I want to reimplement Foo::Bar, I wouldn't be required to use the same versioning scheme as the original Foo::Bar, I would just have to specify that my Foo::Bar implementation uses the same API version. This also solves some problems with specifying a particular module version number. You can instead state that your program uses a particular API version. Then, the module author can fix bugs and increment version numbers as much as he likes, and, so long as he doesn't change the API, those module versions are completely acceptable to use (I claim that if your program breaks due to a newer module version that doesn't use a new API, then either the module author lied and really did change the API, or your program is broken because it depends on features that aren't part of the API). Similar to the emulates attribute, there could be some way of specifying that a new API version is compatible with an older version. You would declare this if the new version only added functionality and didn't change syntax/semantics of existing features. Zev [EMAIL PROTECTED] wrote: > Author: larry > Date: Fri Mar 9 16:38:18 2007 > New Revision: 14325 > > Modified: > doc/trunk/design/syn/S11.pod > > Log: > As noted by allbery_b++, Smylers++, and david.green++, we've thoroughly > neglected to thoroughly spec the intended version sharing and emulation model. > > > Modified: doc/trunk/design/syn/S11.pod > ============================================================================== > --- doc/trunk/design/syn/S11.pod (original) > +++ doc/trunk/design/syn/S11.pod Fri Mar 9 16:38:18 2007 > @@ -12,9 +12,9 @@ > > Maintainer: Larry Wall <[EMAIL PROTECTED]> > Date: 27 Oct 2004 > - Last Modified: 8 Mar 2006 > + Last Modified: 9 Mar 2006 > Number: 11 > - Version: 16 > + Version: 17 > > =head1 Overview > > @@ -351,6 +351,41 @@ > > specifically rules out any prereleases. > > +If two different modules in your program require two different > +versions of the same module, Perl will simply load both versions at > +the same time. For modules that do not manage exclusive resources, > +the only penalty for this is memory, and the disk space in the library > +to hold both the old and new versions. For modules that do manage > +an exclusive resource, such as a database handle, there are two approaches > +short of requiring the user to upgrade. The first is simply to refactor > +the module into a stable supplier of the exclusive resource that doesn't > +change version often, and then the outer wrappers of that resource can > +both be loaded and use the same supplier of the resource. > + > +The other approach is for the module to keep the management of its exclusive > +resource, but offer to emulate older versions of the API. Then if there > +is a conflict over which version to use, the new one is used by both users, > +but each gets a view that is consistent with the version it thinks it is > +using. Of course, this depends crucially on how well the new version > +actually emulates the old version. > + > +To declare that a module emulates an older version, declare it like this: > + > + class Dog:<1.2.1 cpan:JRANDOM> emulates :<1.2.0>; > + > +Or to simply exclude use of the older module and (presumably) force > +the user to upgrade: > + > + class Dog:<1.2.1 cpan:JRANDOM> excludes :<1.2.0>; > + > +The name is parsed like a C<use> wildcard, and you can have more than one, > +so you can say things like: > + > + class Dog:<1.2.1 cpan:JRANDOM> > + emulates Dog:auth(DCONWAY|JCONWAY|TCONWAY):ver<1.0+> > + excludes Fox:<3.14159 http://oreillymedia.com> > + emulates Wolf:from<C# 0.8..^1.0>; > + > =head1 Forcing Perl 6 > > To get Perl 6 parsing rather than the default Perl 5 parsing,
