Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[svn:perl6-synopsis] r14325 - doc/trunk/design/syn

6 views
Skip to first unread message

la...@cvs.perl.org

unread,
Mar 9, 2007, 7:38:20 PM3/9/07
to perl6-l...@perl.org
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 <la...@wall.org>
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,

Zev Benjamin

unread,
Mar 15, 2007, 5:14:01 PM3/15/07
to perl6-l...@perl.org
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

Larry Wall

unread,
Mar 16, 2007, 8:29:21 PM3/16/07
to perl6-l...@perl.org
On Thu, Mar 15, 2007 at 05:14:01PM -0400, Zev Benjamin wrote:
: 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.

I was thinking that "emulates" encompasses that notion, but maybe we
haven't got the name quite right. And maybe we need an API naming
convention.

Larry

John Macdonald

unread,
Mar 16, 2007, 11:38:14 PM3/16/07
to perl6-l...@perl.org

I was thinking "extends <version>" would mean that any program
that depended upon the named version would still work, although
this version extends the interface so that programs that fully
use the extended interface would not work with the older version.
"equivalent <version>" on the other hand, implies that the interface
is forward AND backward compatible (presumably the underlying
implementation has changed for some good reason).

--

0 new messages