HaloO, Jonathan Lang wrote:
Assuming that I understand the terminology correctly, I'll go further and say that one of the big differences between roles and subtypes (using the terms in their perl 6 contexts) is that roles conceptually operate on intension sets - everything about them is defined in terms of their set of capabilities - while subtypes (i.e., objects with "where" clauses) operate on extension sets - they're defined in terms of the valid set of instances.
You understand the terminology correctly. I'm kind of split of which approach to favor. I can understand Smylers objection that the very existence of these two sets and the contradictory results that set ops produce on them should prevent the usage of set syntax for type construction. OTOH, I know of nothing else that conveys the intent as terse.
Incidently, I'm using terms like "supertype", "subtype", "superrole", "subrole", etc. strictly due to a lack of a better alternative. "Supertyping" only leads to a larger set of instances because a parameter that asks for the supertype is willing to accept a subtype in its stead.
Yes, this is how the argument goes. A supertype constraint allows more instances to pass the test because the set of requirements is smaller.
That's the brittleness: the set of methods that you are permitted to define in the superrole is restricted to the set of methods in the role being generalized.
But that makes no sense at all because these are the ones which are specialized further down in the subtyping chain. There has to be some extra that the supertype defines for the subtypes.
Since Num doesn't include methods re or im, an attempt to include either method in a Complex superrole would be an error according to this approach, or it would involve changing Num to include methods re and im in the alternative approach.
Then I did read Luke's post wrongly. Sorry.
The write-up that I saw in the original message seems to carry the implication of the alternative approach (of back-editing the new methods into the subrole). Note that if you go this route, you really should allow yourself to define multiple versions of the new method: one for the superrole, and one for each of the subroles used to define it. I'd rather not go this route, though.
Hmm, looks like this is exactly where I intent to go. If we detach method dispatch from the class that in the end provides the method table for its instances we get the picture that the Complex supertype creates dispatch targets for &im:(Num) and &im:(Complex) and since Num <: Complex dispatch goes to the simple 0 returning role default when called on a Num. So to support supertyping the lookup process of methods has to scan upwards in the inheritance and role hierarchy instead of just looking into a table in the class the object is blessed into. But I think this is how dispatch works, doesn't it? The lookup result might be cached for efficiency.
Look at it according to the normal flow: if you subtype a role with read/write capabilities, the new role cannot have fewer rw capabilities than the role that it's composing has. Reversing this, if a role does not have a particular rw capability, then a superrole cannot add it. This is a variation on the "adding methods to the superrole" debate.
Well, and of the debate of how to retype an object. I see the .im method in a position to do the right thing when given the invocant and the rhs of the assignment. The thing I don't know is how the syntax looks like. Does one write a STORE block into the method body? And how is the container involved in the process?
Mind you, once you've defined a supertype, you can freely create new subtypes of it, and you can add whatever features you want to those new subtypes, be they lvalue access, new methods, or anything else.
This is unquestioned. But my whole point is to get the Num nicely embedded in the Complex without touching the Num implementation.
IMHO, the correct way to create an unordered Complex role from a Num role is to use supertyping to remove the ordering capabilities from Num, and then use subtyping to add "imaginary component" capabilities to that. Yes, this means that a simple partial ordering check between Complex and Num will result in a "no relation" result; but that's a shortcoming of the type-checking system, not the type definition system.
Sorry again, the whole point is to get Num <: Complex in the first place. How else should a subtyping directed dispatch system pick methods? No relation can also be achieved with a unrelated implementation of Complex. Regards, TSa. --
