HaloO,
Rob Kinyon wrote:
On Nov 2, 2005, at 9:02 PM, Jonathan Lang wrote:
Let's say you have this:
role A {method foo() { code1; } }
role B {method foo() { code2; } }
I think, A and B might just be aliases to the *identical* structural type
because the only constraint that both roles impose on their implicit type
parameter is the presence of a method foo() on the type of just this
parameter. The implementation parts are of course different. In other words
the roles A and B are interchangable as far as the structural type checker
is concerned! That is there is a
theory T{^R} { multi foo (^R) {...} }
A ::= T{A};
B ::= T{B};
&A::foo.block ::= &code1; # or however .block is spelled
&A::foo.block ::= &code2; # or { code2; } ?
role C does A does B {
method foo() { A::foo(); }
method bar() { B::foo(); }
}
Should the following be valid?
role D does C { method foo() { B::foo(); } }
IMHO, it shouldn't, because D doesn't do B.
Additionally, D most certainly does B. That it does B through a proxy
is irrelevant. Think about it this way - if you had Surfer and Dog and
"SurferDog does Surfer does Dog", wouldn't you want to know that
"class ScoobyDoo does SurferDog" does Dog?
Semantic wise or type wise?
If SurferDog doesn't do Dog, how would ScoobyDoo do Dog?
Assuming that the type system supervises the constraint addition
in role composition, a meta information lookup on SurferDog should
yield all you need to know about what kind of thing it is!
Just think of electrons and the double slit, if you don't require
them to know through which slit they passed, they don't bother to
remember it ;)
I think this is too restrictive, D should be able to freely
disambiguate or override using anything it want's to. It need not be
related at all to it's subroles.
Well, it can't step out of the frame that the constraints of C impose.
Actually it can because not all contstraints are computer enforceable
but it shouldn't for social reasons.
To further expand on this, D's disambiguation of method foo() could be:
role D does C { method foo() { Completely::Unrelated::foo() } }
Yes, of course. But these are the boring cases. More interesting is
something like
role X
{
method foo (: XA $a, XB $b --> XC ) {...}
}
role Y does X
{
method foo (: YA $a, YB $b --> YC ) {...}
}
where the definition of Y should succeed only iff Y::foo <: X::foo
which requires YC <: XC and (XA,XB) <: (YA,YB) where <: denotes the
subtype relation.
--
