In a message dated Mon, 21 Aug 2006, Jonathan Scott Duff writes:
But, assuming for the moment that C<is Mammal> autoloads C<Mammal.pm>,
does that mean that
class Dog is Mammal-4.5
is valid?
Yes, it must be valid. See
http://dev.perl.org/perl6/doc/design/syn/S11.html#Versioning :
So you can just say
my Dog $spot .= new("woof");
and it knows (even if you don't) that you mean
my Dog-1.3.4-cpan:JRANDOM $spot .= new("woof");
For this not to extend to subclassing seems bizarre.
This seems like something we shouldn't encourage as it
tends toward tight coupling of implementations where it should be
tight coupling of abstractions.
Different sites have different needs. Sites with strong regulatory or
auditing requirements to not modify existing code without review (where
the definition of "modifying" includes changing upstream dependencies)
must be able to specify the longname of classes in this context. Tight
coupling should not be encouraged, but it must be allowed for these cases.
My question is, if a program is running where two versions of Dog are
loaded, say 1.3.4 and 2.1, and a file contains:
use Dog-1.3.4-cpan:JRANDOM;
class Poodle is Dog {
...
}
will the compiler know that 'Dog' in this file must always refer to 1.3.4,
and not 2.1, as most other references to the shortname would? If not,
sites that need dependency stability will have to write
use Dog-1.3.4-cpan:JRANDOM;
class Poodle is Dog-1.3.4-cpan:JRANDOM {
...
}
which I don't necessarily have any problem with, but this behavior needs
to be defined.
Incidentally, isn't C<(Any)> in longnames supposed to be * now? S11 still
uses C<(Any)>.
Trey
