[Prev][Next][Index][Thread]
Class Slots
Hello,
The latest development version of Gwydion Dylan now supports class
slots. During implementation, a number of questions came up, which we
couldn't answer. Maybe someone here knows more.
Andreas
>From the gd-hackers mailing list:
From: Hugh Greene <hugh_greene@yahoo.com>
Subject: Re: Class slots
To: gd-hackers@gwydiondylan.org
Date: Thu, 08 Feb 2001 21:50:26 +0000
"with-no-lurking" // again ...
At 18:07 08/02/2001 +0000, Douglas Michael Auclair wrote:
>Dear Gabor,
>
> Great news on your class slot work. So, what did you decide for
> initialization/assignment of values to the slot? Please share other
> gems, too.
When I once head-scratched about this, I could only conclude that the
language in the DRM was insufficiently clear.
On the one hand, the phrase "each time the slot needs to be
initialized" is used in the "5 Types and Classes / Slots / Init
Specifications" section of the DRM. Does a class slots *need* to be
initialized each time you create an instance of that class? Probably
not; probably just the first time.
Taking that interpretation means you might get some unexpected
behaviour if multiple threads are "racing" to create the first object
of a given class: the value supplied with your init-keyword may be
silently ignored! OTOH, if you re-initialize the slot each time you
create an instance, you can have constant, non-virtual slots which can
change their values! I'm not sure which is less confusing %-)
As for implementing class slots as slots of the class, it's not clear
that the obvious implementation of that would be correct (sorry -- I
meant to reply to this thread before you finished implementing,
Gabor!). In particular, if the slot's storage is shared among
instances, but accessible only via instances, then the value of that
slot may be garbage-collected when there are no reachable instances.
If the slot is tied to the class, you can't GC the contents (until you
set the slot to something else, of course), unless the class itself
becomes unreachable (possible if the class isn't pointed to by a
module constant, as classes normally are). If you expect one
behaviour but get the other, you may suffer from object retention or
unexpected disappearing of information.
I'm sure that makes everything as clear as the proverbial mud ...
"end with-no-lurking Hugh;"