Hi Ned, (well not specifically ;)

Much of what you're saying comes down to a fundamental misunderstanding on
your part - it is that the new/initialize pattern is the _only_ way to
initialize an object and that (once you have created an object) it must be
"properly initialized by default". This is not the goal of the pattern. It
is a convenient short-hand notation which seems applicable in enough cases
to make it generally available.

Perhaps it is worthwhile to highlight the major advantages of the pattern
again (much of this got lost over specific details which - while important -
don't really address the intent of the pattern):

a) Convenience
The pattern is convenient, as you can rely on the fact that if you provide a
default initializer it gets called. The pattern is already a de-facto
standard as pretty much every class that implements an (instance) side
#initialize method expects this to be the default initializer. The pattern
merely recognizes this.

b) Fault tolerance
How often have you written an (instance) initialize method, used it (out of
lazyness) as in "FooClass new initialize" only to recognize at some point
that you really (once more) should implement the new/initialize pattern and
got bitten by the double initialize? I, for myself, more often than I dare
to admit and Squeak itself does contain "double initializers" for exactly
this reason. Introducing the pattern simply avoids those kinds of mistakes.

c) Does not prevent other forms of initialization
Being a pattern rather than a strict rule means that the option of whether
to choose the new/initialize pattern or provide a different form of
initialization is with the author. It _does_ implicitly favour the pattern
(as it is more work to provide a different form of initialization rather
than using the one provided for you) but this argument would only be
problematic if the new/initialize pattern is the _only_ thing you know about
object initialization. Which brings us to the next point

d) It allows controlled exposure to the meta layer
If you've never heard the term "controlled exposure to power" I recommend
reading [1]. In this thesis (albeit being about 3D environments rather than
programming languages) it is shown that the ability to choose - rather than
being forced - when to expose certain kinds of features can dramatically
improve the learning curve. Teachers can choose when to expose the
meta-level rather than "working around its existence". For example, Richards
TaxRule would be a really nice way to talk about how to initialize an object
"properly" to teach good design in the case in question. Without being
forced to it as you can (at first) choose examples which do not require
exposure to the meta level.

In other words, (to get back to Ian's science example) the new/initialize
pattern it is a simplified theory but one which allows us to talk about the
meta-level and discuss the surrounding issues at the point where we choose
to. 

The pattern does not solve issues of classes requiring specific kinds of
initialization (such as TaxRule, FileStream, Socket etc) and it is not
intended for it. It's not a "one size fits all" solution and it is not
intended as such.

It would be nice if we could get the discussion back on these issues rather
than talking about specific cases which the pattern is explicitly not
designed to address.

[1] CONWAY, MATTHEW J. (1997). Alice: Easy-to-Learn 3D Scripting for
Novices. PhD thesis, University of Virginia, School of Engineering and
Applied Science.

Cheers,
  - Andreas