Larry,
On Oct 19, 2005, at 4:10 AM, Larry Wall wrote:
On Tue, Oct 18, 2005 at 07:38:19PM -0400, Stevan Little wrote:
: 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".
But you have to have the aliases there for correct parsing. Otherwise
"Cat" is a bareword, which is illegal. Of course, you can add the
alias without deciding what to bind it to. In fact, within a method,
we require "Cat" to be considered a virtual name, so if a derived
class uses a different Cat, it means that one instead for this object.
I suppose this could be done earlier in the compilation process then,
possibly we can make assumptions along the way and alias short names
immediately, only to retract the alias later if we see something that
conflicts. Assuming we do not encounter any user-level aliasing, I
think this would probably be okay.
However, this brings up an issue I was thinking about. Take this code
for instance:
use Cat-0.0.1;
use PetStore;
my Cat $kitty .= new();
--- in PetStore.pm ---
use Dog;
use Cat-0.0.5;
Which Cat is used? I can see several options:
1) Cat-0.0.1 is used since it is in the local scope, so clearly the
users choice.
2) Cat-0.0.5 is used since it is loaded after Cat-0.0.1.
3) An Ambiguity error is thrown because "Cat" is not specific enough.
Any option other than 1 requires the user to know what is going on
within PetStore.
: 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).
Hmm, don't remember that. But I have a bad memory.
To be honest, I am not sure who I discussed it with, it might have
been autrijus. Either way it was in the early days of the hackathon,
and being a not-so-exciting topic, it was quickly forgotten about for
much cooler topics :)
To be honest, I don't really like this approach anyway.
: 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 think $Larry wants to be strict on this, at least this week.
Horray!
If you're using two different versions explicitly within the same
scope, you should
probably be required to alias one of them. The main purpose of
version
co-existence is for different modules to use different versions, not
the same module. I think using two different versions from the same
module is going to be relatively rare.
Well, the first thing that comes to mind is that you could create a
"best-of-both-worlds" proxy object/module. Say some insane CPAN
developer radically changes an API, some of the changes make senses,
some of the changes clearly illustrate the developers insanity. It
might be useful to be able to create some kind of mix-up of the two
module versions in which you alias part of each API (assuming they
can co-exist peacefully that is).
Sure it's an out-on-the-edge case, but I could see some possible
usefulness.
Stevan
