On Wed, Oct 26, 2005 at 12:22:07PM -0400, Stevan Little wrote:
: On Oct 26, 2005, at 12:05 PM, Larry Wall wrote:
: >Of course, there are other words that are somewhat synonymous with
: >"class", Unfortunately "sort" is already hosed. Maybe "kind".
: Actually "kind" is used in the "Core Calculus for Metaclasses" paper
: which I brought to the hackathon (not sure if you got to read it or
: not). Here is a link:
: They present an rather interesting view on things, that the
: definition of the instance creating portion of a "class" should be
: seperated from the "class" or "kind" portion of the class. Actually
: the first metamodel prototype grew out of an implementation of the
: model they describe in the paper.
Interesting. I didn't read it, but a bunch of us seem to be converging
on the same elephant. I'm thinking of "kind" as the actual type of a
real instance separate from the machinery. I think it probably corresponds
to what Luke is saying about classes not really having names.
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.
At the moment, I think the weakest word choice is "subtype".
People from certain cultures will confuse subtypes with subclasses.
The notion of constraints or limitations is already conveyed by
"where", and some subtypes may just be aliases. Plus, as we've defined
them above, subtypes are the most generic type you can name in Perl.
So maybe we should go with "type"...which is yet another thing I've
waffled on repeatedly...