Roel Wuyts <wuyts at iam.unibe.ch> wrote:
	The whole point is:
	- that there is an obvious need for this, seen that there are around 80 
	identical sibling methods in the system.

The methods aren't siblings.
80 methods out of who knows how many thousands is NOT an obvious need
for anything.
Evidence that there is need for *SOMETHING* is not evidence that there
is a need for a PARTICULAR change.

	- that a lot of these are actually valid - it is not that all of them 
	need a parametrized initialize.
	
Er, nobody has actually presented any evidence for that yet.
Remember that Class>>initialize (or Behavior>>initialize, whichever it
is, I don't care) is not at issue; that's longstanding documented behaviour.
Remember that Morph>>initialize is not at issue; Morph can do whatever it
wants, no-one forces me to subclass Morph.
When you take those out, there aren't many uses of #initialize left in
the system, and many of those are clearly bad design.
Neither Class nor Morph needs, and neither will benefit from, the change.

We DO have evidence that many uses of the (anti-)pattern in the system
are bad design.  We do NOT yet have evidence "that a lot of these are
actually valid", if "valid" means "good design."

Perhaps someone could post such evidence.

	Objections I have read are:
	- will break existing books/culture/history

AND, don't forget, there's a rival proposal on the table which has
the same benefits but DOESN'T break existing books/culture/history.
Don't forget that, because it's a very important point.

Make #new call #initializeYourself and you don't break things.
Code that takes advantage of the change will have to be revisited
and in many cases rewritten anyway, so it might as well be renamed
at the same time.

	- enforces a bad programming practice (of not having appropriate 
	initialize methods that take necessary arguments)

No, nobody has said "enforces".  That's a straw man.
What has been said is that it *encourages* bad design.

	- might introduce problems for people confusing #initialize with #reset,
	
	But at least one thing is very clear to me: an alternative is needed 
	for the current situation.

Well, this particular bat has been fluttering around in a certain belfry
since at least 1999, and there has _not_ been any great outcry of need for
it in since then.  We _have_ design alternatives.

The really sad thing is that if we assume that it IS true that there's
a problem which badly needs fixing, the proposed change doesn't fix it.
The problem is that instance creation in Smalltalk requires the class
AND the instance to both do something.  The proposed change will sweep
*some* occurrences of the problem under the carpet, but it will do nothing
at all for the others.

A change to Squeak that *really* addressed the fundamental problem
would be extremely interesting.

Failing that, a change to Squeak that addresses one (demonstrably minor)
occurrence of the problem WITHOUT BREAKING WORKING CODE is possible and
could go in tomorrow, as far as I'm concerned.

But a change that breaks working code and doesn't really address the basic
problem is not, to my mind, a good change.