[Prev][Next][Index][Thread]
Re: Need help with Class-Allocated Slots
On Wed, 28 Jun 2000, Gregory T. Sullivan wrote:
> >>>>> "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 ... would add to the generic named foo a method with the
> signature
> (c == <a>) => <integer>
>
> whereas a same-named [instance] slot ... would add a method to the foo
> generic with a signature
> (o :: <b>) => <integer>
Right. The only issue is if we want to keep (for utility and/or backward
compatibility) a "springboard" method for each class slot which looks like
define method foo (c :: <a>) => (i :: <integer>)
c.object-class.foo
// We could just use "<a>.foo" for class slots; but for each-subclass
// slots we need to explicitly call "object-class" (though that might
// well be statically optmised).
end;
I'm not sure whether or not we do but, if we do, it makes just as much
sense to be able to override this in subclasses (for both class and
each-subclass slots) as it does to be able to override accessor methods
for instance slots (which we can already do and which can be very useful).
Hugh
References: