About KCP and automatic initialize
Stephen Pair
stephen at pairhome.net
Wed Sep 17 14:14:19 UTC 2003
Hi Andreas,
That's interesting (about E)...as you might have guessed, I was drawing
on Self where all objects are created by cloning...I find a lot of zen
in Self's approach.
If you'll pardon a bit of implementation discussion: you could add an
inst var to Behavior (called examplar if you like) and alter the
instance creation primitive (used by Behavior>>new) such that it if this
inst var is not nil, you create a new instance by copying the exemplar
(if it is nil, just fall back on the old logic). For variably sized
object creation, the primitive would copy the examplars slots, but the
new instance would be sized according to the parameter (as passed to
Behavior>>new:)...if the new size is larger than the exemplar, the extra
slots are nilled, and if smaller, we just copy fewer of the exemplar's
slots. This would take care of backward compatibility with the old
instance creation patterns.
Then, we would be in a position to consider new instance creation
patterns based on two cloning primitives (one for like sized clones and
one for clones of a different size). We could for example create new
instances by cloning the examplar:
Set exemplar clone: 5
Because we would need to do initialization based on the size requested,
we would override the #clone: method on the instance side of Set to do
the following:
clone: nElements
| answer |
answer := super clone: nElements.
answer initArray: (array clone: (self class sizeFor: nElements)).
^answer
The Set>>#initArray: method would simply be:
init: anArray
array := anArray
There are a couple of interesting aspects to this approach...first, we
don't need to set the tally to zero because the Set exemplar (which we
cloned) already has that instance variable initialized to 0. Second, we
don't ever explicitly refer to the Array class because we simply clone
the array instance variable in the Set exemplar...thus, one could
substitute some object of a different class to use for a Set's array.
Further, this instance creation and initialization protocol could be
used using any instance as an examplar (not just the default examplar
associated with the Set class). So, if I have body of code that wants
to create Sets using a LargeArray instead of a regular Array, I simply
create my own examplar and clone it to create my new Set instances.
- Stephen
Andreas Raab wrote:
>Hi Stephen,
>
>Just briefly: I really like this proposal as it gets into an area where we
>look at an "exemplar" for some class rather than the class itself. This is
>very much along the lines of E where (for example) you define an _object_
>rather than a class if you write something like:
>
>def pointMaker(x,y) : any {
> def point {
> to getX(): any {x}
> to getY(): any {y}
> }
>}
>
>"point" in the above is not a class but rather an object which responds to
>the #getX and #getY message.
>
>Cheers,
> - Andreas
>
>
>
>>-----Original Message-----
>>From: squeak-dev-bounces at lists.squeakfoundation.org
>>[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
>>Behalf Of Stephen Pair
>>Sent: Tuesday, September 16, 2003 5:04 PM
>>To: The general-purpose Squeak developers list
>>Subject: Re: About KCP and automatic initialize
>>
>>
>>Sorry if this has already been suggested (I haven't been able
>>to keep up
>>with this thread), but what about having a prototypical instance
>>associated with each class? New instance creation would happen by
>>cloning that prototypical instance (which would already have its
>>instance variables defaulted to whatever is required). Further
>>initialization that needs to happen on an instance by instance basis
>>could happen by overridding the #clone method (or some other
>>clone-like
>>method used for instance creation). Of course, this wouldn't
>>work for
>>variably sized object, but you could probably fake it in some way.
>>
>>- Stephen
>>
>>
>>
>>
>
>
>
>
More information about the Squeak-dev
mailing list
|