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
>>
>>
>>    
>>
>
>
>  
>