Roel Wuyts <wuyts at iam.unibe.ch> wrote:

	I am trying to follow the discussion, but I am a bit confused.
	With all the arguments thrown around, it seems that the proposed
	mechanism (automatic initialize) is just a finer grained
	mechanism.

I don't know what you mean by "finer grained".
It is a change to a core method in a core class.

	This will not stop you from using specific instance
	creation methods (which I strongly prefer for those cases where
	you can).

Nobody ever said it did.

	So what is the problem?

IT CAN BREAK WORKING CODE.

	I do not see why this promotes bad design whatsoever.  To the
	contrary, I am convinced that this will absolutely promote good
	design.

On the evidence, this is extremely hard to believe.
Remember, when I looked at four Squeak classes I had never looked at before,
I found that this use of #initialize was a sign of bad design in ALL of them.

	How many methods are duplicated currently?

What has that got to do with it?  The proposed change has nothing to do
with the majority of duplicated methods.  I showed that the *total* number
of calls to "super new initialize" in Squeak 3.5 was on the order of 80;
some of those might not be eliminable.

	Is that good design?

Sometimes it can be.  Nobody is objecting, by the way, to system classes
*other* than Object sending whatever they please in #new.

	Is it good design that there exist so many sibing methods?

I don't know what you mean by "sibing methods", and on any ordinary
understanding of "sibling" I don't see how the proposal would or should
do anything to reduce the number of sibling methods.

The question is whether it is right to introduce a change that can break
working code in order to make it easier to do something right which is
already perfectly simple to get right without the change.