Hi andreas

I and the KCPers agree 100%. We got those discussions or common 
agreement for so many time
at Berne...We are really in sync on this point.

You convinced me :). I buy it!
(I should admit that you are much better than me to communicate, even 
if I'm trying hard
to write sentences that people can read. My flu does not help me. :))
So how do we proceed now? I hope this change will be the first one to 
go in 3.7
with the wonderful look of diego and all the rest...for a better future 
that we are inventing.

Stef

On Lundi, sep 15, 2003, at 22:32 Europe/Zurich, Andreas Raab wrote:

> 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
>
>
>
>