clarify: does "Dog is Mammal" load Mammal for you?

class Dog is Mammal
http://dev.perl.org/perl6/doc/design/syn/S12.html

However, it's not clear if it is necessary to preload Mammal for Dog
to function properly here, or what that syntax would be.

Testing with current version of pugs, this doesn't happen. Adding
"use Mammal" before this syntax seems to fix it, but doesn't seem like
it should be necessary, especially since "use Mammal" has traditionally
implied as "has-a" relationship.

Mark

If "is Mammal" were to cause an implicit "use Mammal", then I would expect
this to happen only conditionally, such as if no "Mammal" has yet been
declared in some already used (or the current) file (it may be declared in
a file not named "Mammal". Even then, I don't know if this implicit 'use'
action would be a good idea, as it may be a source of bugs. -- Darren Duncan

I've been under the impression that Mammal wouldn't have to be
preloaded, but it would have to be sufficiently defined before
the end of compilation. Whether that comes in the form of
C<use Mammal> or some other construct, I don't know.

As far as C<is Mammal> autoloading, right now, I'm of the opinion that
the programmer should be explicit about loading the code that defines
Mammal but I don't have a strong argument for that position.

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? This seems like something we shouldn't encourage as it
tends toward tight coupling of implementations where it should be
tight coupling of abstractions.

I don't know ... someone argue my brain into a new position :-)

-Scott
--
Jonathan Scott Duff
du...@pobox.com

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.

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

I misstated my worry here. In this case, by the same rule that "my Dog
$foo" gets the right version because the longname is aliased to the
shortname in the lexical scope of the use, it would work.

What I'm actually concerned about is the case where the Dog CPAN
distribution includes Poodle.pm. I think that we need Poodle.pm to be
written like:

use Dog-1.3.4-cpan:JRANDOM;
class Poodle-1.3.4-cpan:JRANDOM is Dog { ... }

If it's written:
use Dog;
class Poodle-1.3.4-cpan:JRANDOM is Dog { ... }

then in a running Perl program that has previously loaded Dog-2.1-*,
Poodle-1.3.4 will become a subclass of Dog-2.1, which causes any code
using Poodle-1.3.4 to be unable to protect itself from an unforseen
upstream dependency change.

Such wordiness seems unfortunate and error-prone. I don't believe the
specs yet have anything to say about how filesystem layout exists in the
world of versioned packages, but it would be nice if a distribution's
packages can use a shortname and automatically refer to other packages in
the same distribution before the compiler looks elsewhere within %*INC (or
its moral equivalent).

Trey

This is precisely the problem which unix shared libraries have to face
(so yes, it's a real problem), and which is handled by a combination
of sonames and versioned symbols. It seems to me that there is some
merit in considering similar features here. The essential features
are:

- independent version labels for the interface and implementation, so
you can change the implementation while promising that the external
interface remains the same

- individual symbols can be optionally decoupled from the interface
version of the library that contains them and versioned
independently, so even though the interface version has changed from
X to Y, the linker knows that only function foo has changed; clients
that use only function bar will still find this version acceptable.

Shared libraries make this behaviour optional, with the first being
all that most people use, and the second only being used by people
writing large libraries with complex needs (like glibc).

You can get interface versions with nothing more than a stipulation
that Poodle-1.* will always have the same interface, but everybody has
to understand what this means for it to work. I'm not sure if this is
the right approach here.

It is not clear to me whether it is practical to version individual
symbols in perl6 as it currently stands, but it would appear to be
worthwhile to make sure this is possible.

I suspect that this will largely be a matter of establishing
appropriate conventions about versioning for CPAN modules.