[Prev][Next][Index][Thread]
Re: Need help with Class-Allocated Slots
On Wed, 28 Jun 2000, Scott McKay wrote:
> 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.
I'm *not* saying you should be able to override a class slot with an
instance slot. (I can imagine there being a workable model for that but I
don't think it's useful or desirable.) What I am saying is that you can
already add specialised accessor methods for subclasses which can do
whatever they like, including: *effectively* change the allocation by
accessing a hash table or new instance slot or a random number generator
or something; printing a debug message, then doing whatever the superclass
does; not terminating when called.
So ... Being able to override slot accessors in subclasses is *very*
useful and shouldn't be prevented. But if we allow it, we can't feasibly
stop people doing broken things with it. (We can prevent -- indeed, can't
avoid preventing -- some broken things, like changing the type signature;
but not everything.) We could, however, illustrate "best practice" and
persuade people to do that. In this case, if you want to mess with
allocation in subclasses but want a default of "class", the best way is
probably to have a superclass "virtual" slot and a subclasses which
implements this in terms of a class slot (plus any other subclasses you
want, implementing it however you want).
(Okay, we *could* theoretically enforce the behaviour of class or
each-subclass allocation by having descriptions of invariants to check
for all instances, every time you access such a slot, but that's not
feasible!)
> >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.
> >...
>
> Data stored in a class slot can't be GC'ed now until the class itself
> is GC'ed, right?
Well, all the DRM says (in the one place I looked -- it's infamous for
having relevant information spread across several separate pages!) is
class allocation specifies there is only one storage location
used by all the general instances of the class. All the
instances share a single value for the slot. If the value is
changed in one instance, all the instances see the new value.
I *think* there's no value for the slot until the first (successful) call
to "make". (At the moment we can't tell. If we make such slots
accessible via classes, presumably they have to be initialised whenever
the class is "ready", even if no instances exist?) It's not clear (to me,
from the above) whether or not the value could be GCd at any point where
all instances have been GCd. To put it another way, I think you could GC
it and not be inconsistent with the DRM.
(Another bit of under-specification in the same area: it seems to me that
constant class and each-subclass slots with init-keywords can in fact have
their value changed each time "make" is called, because init-values are
inserted by some method other than calling the setters.)
> ... And the class itself can't be GC'ed until you can
> prove that nobody will ever call 'make' on the class again.
Classes created with "make(<class>, ...)" might become unreachable at some
point and hence get GCd. Not common practice, but possible.
Sad thing is, I actually *like* all this twisty language stuff :-)
Hugh
Follow-Ups:
References: