goran.krampe at bluefish.se wrote about:
	> +initializeWithFoo: aFoo bar: aBar
	> 	myFoo := aFoo.
	> 	myBar := aBar.
	> 

	What other consequences could this have?

It introduces a precedent for "derived methods".
For example, if you spot a derived method in a method list,
and click on it, the browser should take you to the method it
was derived from.  If you renamed the base method, the derived
method should be suitably renamed.  If you delete the base method,
the derived method should be deleted.

Automatically generated accessors are pretty similar, really.
If you rename or delete the instance variable, the automatically
generated accessor should be renamed or deleted as well.  (Not that
automatically derived accessors are necessarily a good thing; not at all.)

	But wait, wouldn't it be better with:
	
		MyClass class>>foo: aFoo bar: aBar
	 		^super new initializeWithFoo: aFoo bar: aBar
	
I don't think so, because I think the "+" is all you need, not the
"initialize" prefix.  If you are going to write one method, the method
name you write should be the method name you mean to use.  If you are
going to make objects by doing Myclass foo: x bar: y, you should write

    +foo: aFoo bar: aBar
        myFoo := aFoo.
        myBar := aBar.

	Without taking a side regarding this little "sneaked in" proposal yet -
	I personally *really* think we should take the "lead" and move Squeak
	forward.

This is a complete and total straw man.  Nobody has said, written, whistled,
sung, or implied anything which could have been taken by any reasonable
reader as meaning "Squeak should not move forward".

To resist *one* change on the grounds that it sacrifices backwards
compatibility without gaining much that is worth having is not to resist
*all* changes.

    {} is a change, in my view a really good one.  It doesn't break
    compatibility.

    working blocks is a change that moves Squeak forward.  It not only
    doesn't break compatibility, it increases compatibility with other
    Smalltalks.  (It doesn't break backwards compatibility because we've
    been warned for years that blocks _should_ work properly and one day
    would.)

    SqueakMap is a change that moves Squeak forward.  It doesn't break
    compatibility.

    SAR and DVS are changes that move (or may move) Squeak forward.
    They don't break compatibility:  you can still use change sets if
    you really want to.

    3D graphics was a change that moved Squeak forward.  It didn't
    break compatibility.

    Morphic was a big change that moved Squeak forward (but not nearly
    as much as it might have if there'd been good documentation).  It
    didn't break compatibility; MVC was still there.  For a couple of
    years I ignored Morphic, and was able to.  Now I don't use MVC any
    more, but it was the fact that I _could_ that make the transition
    possible for me.

I could go on and on and on about changes that have already been made to
Squeak that provide really useful advances *without* having to break working
code.  Even alternative syntax has been explored *without* forcing everyone
to switch to it.

If I, for one, was opposed to anything that wasn't Smalltalk-80,
I wouldn't have Self on my machine.  (And if I could figure out how
to increase the character size, or had had any reply to my mail asking
how to increase the character size, I might well have switched to it.
As it is I can't switch to something I can't visually discriminate.)

It is a mistake for designers to stick stubbornly to the change they
first thought of.  It is a mistake to deny the reality of costs as well
as benefits.  It is, in the long run, a mistake to insist on solving
half a problem when a whole solution might be in reach.

All praise to Andreas Raab for suggesting the better way.