[Prev][Next][Index][Thread]
Re: Need help with Class-Allocated Slots
>>>>> "Scott" == Scott McKay <swm@mediaone.net> writes:
Scott> I'm not convinced that overriding a class slot with an instance slot
Scott> should be allowed. A superclass has already effectively declared
Scott> the protocol -- the slot is class-allocated. Why should a subclass
Scott> be allowed to break the protocol? Right now, for example, a subclass
Scott> can't change the type of an inherited slot.
I haven't been following the thread carefully, but as I understand
Hugh's proposal, there is no issue here. To summarize my
understanding of the proposal:
A class slot
define class <a> (<object>)
class slot foo :: <integer>, init-value: 6;
end class;
would add to the generic named foo a method with the signature
(c == <a>) => <integer>
whereas a same-named slot,
define class <b> (<a>)
slot foo :: <integer>;
end class;
would add a method to the foo generic with a signature
(o :: <b>) => <integer>
Accessing the class slot would be done as in:
foo(<a>) or foo(<b>) or <a>.foo or <b>.foo
whereas the instance slot would be done as in:
foo(an-a) or an-a.foo, etc.
There's no issue of "overriding the class slot with an instance
slot". The class slot accessors are specialized on subtypes of
<type>, whereas the instance slot accessors are specialized on
subtypes of, in this case, <a> and <b>.
--
Greg gregs@ai.mit.edu (617)253-5807
Sullivan http://www.ai.mit.edu/~gregs/
Follow-Ups:
References: