On Thu, 2005-04-28 at 09:51, Thomas Sandlaß wrote:
> Ingo Blechschmidt wrote:
> > Hi,
> >
> > so we had junctions of Code references some days ago, what's with
> > junctions of Class and Role objects? :)
>
> I like them! In the type lattice A|B is the lub (lowest upper bound)
> of A and B. And A&B is the glb (greatest lower bound) of A and B.
That's not at all intuitively obvious because what you're describing is
not a junction. At least it doesn't seem like one to me (you're
describing a situation where the new class has a specific kind of
inheritance, not the situation where it's first ancestor is either all
or one of a set). The difference being that in the case of:
class x is y&z {}
my x $a;
$a.foo();
The method "foo" will be invoked from both y and z simultaneously,
without conflict, and return a junction of the two results.
> > role A { method foo() { 42 } }
> > role B { method foo() { 23 } }
> > class Test does A|B {}
>
> Here you have to implement &Test::foo.
> Not doing so is a compile time error---or more
> precisly a class composition time error.
Let's be clear about why you think that. Roles are not ordered, and thus
you must disambiguate the use of more than one. S12 says:
There are several ways to solve method conflicts. The first is
simply to write a class method that overrides the conflicting
role methods, perhaps figuring out which role method to call.
Alternately, if the role's methods are declared multi, they can
be disambiguated based on their long name. If the roles forget
to declare them as multi, you can force a multi on the roles'
methods by installing a multi stub in the class being
constructed:
multi method shake {...}
However, this is a junction, so:
class Test does A|B
is really saying that you compose two different classes called "Test",
which you refer to singly through the magic of junctions. One "Test" is
composed of the base Test class plus A, and another is composed of the
base Test class plus B (well A plus Test and B plus Test if you think of
it in terms of which overrides which).
Now, I'm not saying that that's the way it MUST be, just that that seems
to be the way that junctions would work in that situation. If we decide
that | and & aren't really junction constructors in class/role
definitions, then we can make them whatever we want.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
