Hi Richard,

Please excuse me that instead of replying to your other (rather lengthy)
response I pick this one - it seems to bundle up your points in a much
shorter way and makes it easier to address the concerns on a global level
without having to discuss individual classes and design decisions.

> What we don't have is agreement about whether
>  - the #new-calls-#initialize proposal *IS* better and
>  - whether it makes sense to have a "better" schema for something
>    which should very seldom be used at all.

I think the last point is at the heart of what you've been saying in the
lengthy message - namely that it is almost never correct to use any kind of
zero-argument initializer for an object.

The funny thing about this is that I agree - even to the point you were
making that #new should be a "self shouldNotImplement" in many classes.
However, what you are talking about now is a builtin problem in Smalltalk.
You absolutely have to go to the meta level in order to make any other kinds
of initializers. And that's the real problem.

Most people (even experienced ones) don't "get" the meta level. It is
dangerous to use the meta-level for casual stuff. Many other languages
provide some form of initialization messages (constructors) without having
to expose the meta-level (if it is even accessible).

What the new/initialize proposal gives you is a way to defer that exposure
for a while (which I think we both agree on that it is advantageous at least
in early stages). Unfortunately, we have no alternative at this point -
there is nothing, absolutely nothing we can do to defer the meta-level
exposure in any other way as the syntax of Smalltalk prevents us from
providing any other generalized mechanism. At least unless you want to get
serious about changes to the language. 

It would be trivial with a tiniest bit of modification to the language
itself, merely by providing an attribute to an instance side method which
signifies this as a "constructor message" and simply compiles the
appropriate class-side method, e.g., something like (using "+" as the
"constructor message flag")

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

could simply compile a class-side method which is

MyClass class>>initializeWithFoo: aFoo bar: aBar
	^super new initializeWithFoo: aFoo bar: aBar

Simple, isn't it? It would even address your stated concern about that we
need a pattern that recognizes the problematic issues of using zero-argument
initializers as the system could just implement #new as "self
shouldNotImplement" if it encounters any of these initializations.

So, if we wanted to be real about fixing this issue I don't think we could
stop short of changing the language. I am simply not deluding myself about
the storm of protest that would break loose if anyone would make that
proposal. So the only thing we _can_ do is to come up with a "reasonable
approximation". Now you argue that we shouldn't even do that.

Ho hum. By the end of the day this really means we can't change anything on
a larger scale. Each and any such change would break compatibility with
other Smalltalks. If that is what you're after then you just cannot move
Squeak forward. You can only wait until the other dialects have changed and
play catch-up with them.

Why not instead set the pace?

> One of the things that has annoyed me in the past about Squeak
> is that some great new tool (like the Refactoring Browser) becomes
> available for other Smalltalks, finally (ah, finally, after a LONG
> wait) becomes available for Squeak, but then Squeak changes so I still
> cannot use it.

Which (to me) translates into: Don't change Squeak. Whatever you do will
break something and I don't want anything to change as it may break
something. Sorry, but the only unchanging rule about life and software
systems is that they change constantly. You've got to find a way to live
with it and one simple way of doing it is to stick to a particular version
of Squeak until a newer one supports all of the tools/libraries that you
want to use. Of course, unless you actively help to get them forward this
may never be the case. Welcome to the world of open source software.

> We are ALL in agreement that Squeak should move forward.

No, Richard. You are not. And before you write back in a message using all
caps think carefully about what you are saying in this very message. You
simply cannot make an omelette without breaking a few eggs. You cannot make
a better omelette without adding a few new ingredients. And you are
specifically saying that we should not do anything alike.

> We do NOT all agree that this is best done by cutting ourselves off
> from other Smalltalks and other exciting Smalltalk tools.

See above. With being open and free (not "free (tm)" but free nevertheless)
and not burdened with millions of lines of legacy code, it is one of the
Smalltalk dialects which _may_ move forward, which _may_ introduce new
concepts, which _may_ bring the language out of its niche. If compatibility
with dialects which are burdened with legacy code is your primary concern,
then you just cannot move.

> So I am opposed to the proposed change not because I want Squeak to
> be mired in the past but because I *don't* want it to be 
> mired in the past.

In this case, you would have to agree on even more radical changes than the
one proposed here (such as the above change to the language itself).
Unfortunately, I have no evidence that you are in favour of such changes -
quite to the contrary actually considering messages I've read from you in
the past.

> Is there anyone out there who understands my utter FRUSTRATION
> at the way I can never move forward in my Smalltalk practice because
> someone keeps yanking out the rug so that I can never use this tool?
> Anyone who *does* understand that will understand why I refuse to
> consider Kernel Changes in basic language mechanisms on the merits
> they might have if other Smalltalks and other Smalltalkers 
> did not exist.

I understand your frustration but I don't understand why you refuse changes.
Like I was saying the best thing to do for a person who does not wish to use
the "very latest" which may or may not support one's favourite tools and
libraries is to use the one which does. That gives you a very clearly
defined environment in which you can be certain nothing changes unless you
want it to. Using the "latest greatest" is understood by every last person I
know as an implied agreement to cope with the changes the "latest greatest"
brings in. That's just the way it is.

> My other point is that simply *having* a "default 
> initialization schema" is in invitation to error. 
> Experts can cope with the present system and
> with the proposed change.  I'm no expert, and I can.

I think some people would argue to the contrary ;-) (of you being no expert)

> The change is supposed to be for the benefit of beginners. 
> But to me this is like seeing a 4-year-old running with a knife
> in her hand and saying "little one, don't do that, let me give
> you this much sharper knife instead". I cannot see a change that
> makes it easier to do the wrong thing (or rather, something
> which is occasionally sensible but almost always wrong)
> as "better" in any honest sense of the word.

I have outlined a simple solution in the above to address pretty much all of
the points you were raising. Given your somewhat arbitrarily changing point
of view between "do not make things incompatible" and "fix this problem in a
way that addresses the concerns" I do not see how one would achieve such a
thing. If you want to change and fix this issue for real you cannot be
compatible. If you want to stay compatible you cannot even attempt to fix
this problem.

It would be nice if you could clear your mind a little about what it is you
_really_ want. If you want to improve Squeak on a larger scale I would
expect that you happily take up the above proposal and enhance it to address
any further issues you may have with it. Or you may decide that
compatibility is your paramount concern - but then you probably shouldn't
claim that you want to move Squeak forward.

Cheers,
  - Andreas