[Prev][Next][Index][Thread]

Re: Need help with Class-Allocated Slots

On Wed, 28 Jun 2000, Lyman Taylor wrote:
> Hugh Greene wrote:
> .....
> > 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.
> 
>   If there is only one storage location then it would seem that it is 
>   independent of the existance of the instances. In other words it is a 
>   "global variable" and subjects to the permanent non-GCness of such
>   values. While "weak" globals are likely useful I don't see
>   them mentioned. 

Right, and I agree this is the most likely implementation (and there are
only a handful of implementations, so we could check what they do :-).  I
was just enumerating some possibilities I saw.

>   ... The DRM says class slots can be initialized "before or during the
>   creation of the first instance".  If there's to be "instantless" acess
>   then this that "during" probably needs to be dropped ...

Agreed, more or less.  I suppose the right condition would be more like
"before or during the first call to the class slot accessor method" --
what do you think?

>   This may also open up some vulgarities if the initialization expression
>   is nontrival and introduces ordering problems. Which may have been 
>   some of the rationale for allowing this to be done "just in time". 

Right, maybe; but it's already possible to get various complications in
ordering of top-level forms in Dylan, so I don't think this would be
sufficient reason to rule out this change.  We need to be very careful
that we've considered all the angles, though.

Thanks,
Hugh
References: