About KCP and automatic initialize

Andreas Raab andreas.raab at gmx.de
Tue Sep 16 16:01:54 UTC 2003


> There have been so long posts with tons of arguments all over that I
> have lost sight of the issues at hand... It would be 
> interesting to hear a summary. :)

I guess that summary is rather simple. Both sides have two primary
arguments:

Pro:
====
* Convenience and fault tolerance
Meaning that the new/initialize proposal provides a default means of
initializing an object if that is wanted. It prevents typical mistakes of
multiply initializing the object.
* Simpler to learn
Meaning that by having a way of making default initializers we do not need
to expose the meta level as early as we would have to otherwise.

Contra:
=======
* Default initialization is incorrect for many classes
Meaning that there are enough classes where default initializers cannot and
should not be used. The new/initialize proposal can lead to (potentially
incorrect) attempts to initialize objects.
* It breaks compatibility
No other Smalltalk dialect implements the new/initialize pattern today, so
porting things from and to other dialects will get harder by the change.

All other arguments that have been made seem to be minor in this regard.

Cheers,
  - Andreas



More information about the Squeak-dev mailing list