> So maybe we can define our terms like this: > > type: a completely generic metaterm for any of the following, > and then some. > > class: a mutable interface object that manages instances in the > "classical" way, with covariant derivational properties. > > role: an immutable and possibly generic interface class, with > covariant compositional properties. > > kind: the abstract, often unnamed type of an actual instance > or storage location, abstracted from any of its machinery or > degree of definedness. You should not generally declare a "kind", > they just happen. > > subtype: a potentially contravariant type based on any of the > previous types, allowed to impose constraints that are more > selective than a kind is allowed to be. > > Then ^T $x binds T to the kind of $x. And $x.kind == $y.kind asks > if two objects are of the same type, but $x.kind isn't a class-like > object, only an identity of some sort. $x.meta returns the Class > instance, or whatever.
A few questions: 1) Where does prototype-style OO fit into all of this? I hope it's not through repeated eigenclasses (or whatever they're called this week) ... that just sounds too heavy. 2) Isn't Dog|Cat kinda declaring a kind? Thus, can't you say "my Dog|Cat $catdog;" and be talking about a kind? I would think that a "named kind" is just a role ... 3) Aren't classes mutable and roles immutable by default only? Or has this changed? Rob
