This is addressed in S11, here is a link:

To summarize, the syntax to load the modules is:

  use Dog-1.2.1;

While the syntax to create a specific version of a module is:

  my Dog-1.3.4-cpan:JRANDOM $spot .= new("woof");

I addresses the class creation syntax partially in the initial version of the Metamodel prototype, which was built in p5. I basically just aliased the package with the long name (%{"Dog-1.3.4- cpan:JRANDOM::"} = %{"Dog::"}). However this does no good for loading of modules.

I have been giving this some though though, and here is a rough sketch of what I have come up with so far.

Any module loaded is stored into *:: (or the p5 *main::) as the longest name given. This means that if I do this:

 use Dog-1.2.1-cpan:JRANDOM;

Then I have an entry for "Dog-1.2.1-cpan:JRANDOM" in the symbol table. If, further along in the compilation process, I encounter another Dog, such as:

 use Dog-0.0.2-cpan:LWALL;

Then this is added as "Dog-0.0.2-cpan:LWALL" into the main symbol table. Then once the compilation process is complete, I traverse the symbol table hierarchy collecting all the names. Any duplicate short names (Dog) are noted for later. Once I have collected all the names, I build all my aliases.

So if I find:

  use Cat-0.0.1-cpan:JRANDOM;

only once, I build an alias for (at a minimum) "Cat" and "Cat-0.0.1". For my duplicates, the table would look something like this I think:

  Dog       => Dog-1.2.1-cpan:JRANDOM
  Dog-1.2.1 => Dog-1.2.1-cpan:JRANDOM
  Dog-0.0.2 => Dog-0.0.2-cpan:LWALL

We are explictly giving the preference to the later version number (I think we discussed this at the Toronto hackathon).

Another school of thought would be that "Dog" alone would be considered ambiguious and so we would just alias far enough to be clear, like this:

  Dog       => Ambiguity Error!
  Dog-1.2.1 => Dog-1.2.1-cpan:JRANDOM
  Dog-0.0.2 => Dog-0.0.2-cpan:LWALL

Of course, this means that if I also load "Dog-1.2.1-cpan:LWALL" that the table looks like this:

  Dog       => Ambiguity Error!
  Dog-1.2.1 => Ambiguity Error!
  Dog-0.0.2 => Dog-0.0.2-cpan:LWALL

And the user is now forced to add the cpan id to get Dog-1.2.1. I am not sure how strict @Larry wants this to be.

I have been meaning to do some kind of p5 prototype of this, I can push it up the TODO list if it would help you.


On Oct 18, 2005, at 5:41 PM, Nicholas Clark wrote:

Sorry if I'm asking a question that I've missed in a synopsis.

Perl 6 will be able to load more than one version of the "same" module.
As I understand it, this would let you have more than one version of
"DBI" loaded in the same interpreter, and also have DBI written by Tim Bunce
and "DBI" written by A.U.Thor in the same interpreter.

Is the syntax for accessing different versions of the same module from Perl
nailed down yet?

Specifically this is in reference to wondering if the multiple module trick
would actually be possible in perl 5: msg00585.html

and how to do something functionally like:

  my $foo = DBI(1.38)->new();
  my $bar = DBI(1.40)->new();

or whatever to distinguish which you wanted to call a class method on.

Nicholas Clark

Reply via email to