> That's just self.meta.add_method($label, $method) by my lights. > A .meta already implies/ignores the .class coercion. If we are to > support prototype-based programming $x.meta *must not care* whether > it has been given a class or an instance or something in between. > What I am calling a "class" here is basically that portion of the > current instance that is the same for all members of its class. > And that common information presumably includes information on what to > do if a method is called that is not directly recognized by the object. > Class-based and prototype-based systems have different answers to that, > but they have something in common, and I'd like to abstract that out > and call it something. I've been calling it "class", but maybe I > should call it something else to avoid confusion. A "type" maybe. > That would imply that ¢ is really a "type" variable rather than a class > variable. But maybe "type" is too overloaded already. But maybe not.
I'd like to take this moment and point to my somewhat hand-wavy metamodel proposal from last week. When Stevan and I were talking about this, we called it a "quark." "Atom" also works quite nicely, but quarks are cooler. Plus, if you think about the definitions that go into creating an instance (class, role, prototype, etc), it makes sense that if the instance is the smallest indivisible thing there is, then the things that go about being its definition are the quarks. > Anyway, if my "class" turns into "type" or something else, maybe I > can be persuaded to go with ^T instead of ¢T. Q(T) ? :-) Rob
