On Wed, Oct 19, 2005 at 09:33:39AM -0400, Stevan Little wrote: : 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.
Yes, especially if the result of a collision is somewhat fatal, so we don't really have to try to undo anything. Another reason for taking the strict line. : 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: They alias Cat differently in their lexical scope. $kitty is a version 0.0.1 kitty. If $kitty is is passed into PetStore, methods on it still call into Cat-0.0.1. If PetStore makes a new cat, it's a 0.0.5 cat. Whether different versions of cat are interconvertable probably depends on whether 0.0.5 supplies the appropriate conversion functions for earlier versions of Cat. Possibly these can be assumed in some cases, such as when the attribute list hasn't changed. : 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. 4) The Cat alias is lexically scoped, and two different scopes can have two diffferent aliases. : Any option other than 1 requires the user to know what is going on : within PetStore. I think it just requires that later versions of Cat know how to deal with earlier versions. : >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. Well, sure, I'm not trying to disallow it, just re-Huffmanize it. The explicit aliasing mechanism (using :as<NewCat>, perhaps) should be sufficient to handle the marginal cases without complicating the implicit aliasing mechanism. The exporter is already in the business of aliasing various names into the current namespace, so making it alias the whole module is no big deal. No need for extra built-in syntax. Larry
