[EMAIL PROTECTED] writes:
: Note that it may not be possible to satisfy conflicting requests. If
: module C<A> and module C<B> demand two different versions of the same
: module C<C>, the compiler should halt and state the module conflicts.
Pardon me for sniping at a great RFC, but I already promised the CPAN
workers that I'd make that last statement false. There's no reason in
principle why two modules shouldn't be allowed to have their own view
of reality. Just because you write Foo::bar in your module doesn't mean
that Perl can't know which version of Foo:: you mean.
The issue is actually more general than just versioning. The larger
view of it is how to support package aliasing. A package name is
essentially the name of a public interface. Suppose you have one
interface, but two or more different implementations of that interface
by different people. Each might have their own version sequence.
There are open questions on that, of course. If we have two different
packages of the same name differentiated only by version or by author
(or both), we obviously count that internally as part of the name of
the package. To what extent do we need to reveal the full internal
name of a package? (For instance, does the author/version show up as
part of the name when you say "ref $object".)
Another question is whether the two different versions of the "same"
module are going to stomp on each other? (Not in package space, since
the packages are distinguished internally, but how about in the
filesystem?)
There are also policy issues with package naming. When and how do we
declare that a package name like XML::DOM is a standard abstract
interface that belongs to no one implementation, and restrict version
numbers to interface revisions, not implementation revisions?
Basically, there are some more things we have to think about if we
really want to do Best Fit rather than First Fit. And I think we do.
Larry
