[Prev][Next][Index][Thread]
Re: Need help with Class-Allocated Slots
Hugh Greene wrote in message ...
>On 27 Jun 2000, Neel Krishnaswami wrote:
>> Andreas Bogk <andreas@andreas.org> wrote:
>> > "Scott McKay" <swm@mediaone.net> writes:
>> >
>There's still the question of whether it should be allowable to override
>these methods (both class-accessed and instance-accessed) in subclasses
>(assuming no sealing prevents it), potentially changing the
>effective allocation. I think the answer has to be "yes", because you can
>already do that for all kinds of slots in Dylan.
I'm not convinced that overriding a class slot with an instance slot
should be allowed. A superclass has already effectively declared
the protocol -- the slot is class-allocated. Why should a subclass
be allowed to break the protocol? Right now, for example, a subclass
can't change the type of an inherited slot.
>Oh yeah, one last thing. Another slight semantic change(?) if we can
>access class slots via classes is that data stored in them can't ever be
>GCd (until it's replaced, or the class itself is GCd). In the current
>scheme, it's not clear whether, whenever all instances of a class with
>class slots have been GCd, the data in the class slots should also be GCd.
>I don't think this is a point against making class slots accessible via
>the classes; I just mention it in case it would change the semantics of
>any existing code.
Data stored in a class slot can't be GC'ed now until the class itself
is GC'ed, right? And the class itself can't be GC'ed until you can
prove that nobody will ever call 'make' on the class again.
Follow-Ups:
References: