About KCP and automatic initialize

Daniel Vainsencher danielv at netvision.net.il
Tue Sep 16 11:17:04 UTC 2003


The gist of your argument, IIUC, is that zero-argument initialization is
often bad design, and therefore we shouldn't encourage it by making it
easier. Therefore, we shouldn't make new call initialize by default,
because that does make it easier.

I disagree - I believe this position doesn't do justice to two key
distinctions.
A. Zero argument initialization is sometimes good design, and means to
sometimes correct ends should be provided. The meta-level-hiding
argument applies here.

I agree that zero argument initialization is often bad design. Even
ignoring correctness arguments about class invariants, "new" as a
creation interface is not intention revealing, and also not concise, if
it then require more method calls to configure the object for use. But -
B. Design is one of the learning curves that beginners need to climb, in
addition to technically correct usage of of the language. However, those
are separate curves. Someone could come to Smalltalk with a good design
background, and decide that they actually need zero argument
initialization, and this should not be made difficult in this language.
Someone with less design knowledge might not realize at the outset that
a zero-arg-init is bad for his case, and still reach that point by using
the new and initialize as temporary means. It is better to allow people
to improve something that at least marginally works, than to try to
teach them Smalltalk (with some meta-level stuff) and design at the same
time.

Daniel

"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
> ducasse <ducasse at iam.unibe.ch> wrote:
> 	I do not understand why simply having a better default
> 	initialization schema that let everybody breaks the rule the way
> 	he wants is a problem.  But may be this is because Smalltalkers
> 	always want to cry that they are so cool but less and less.
> 
> This is an ad hominem attack.
> 
> 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.
> 
> 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.
> 
> We are ALL in agreement that Squeak should move forward.
> We do NOT all agree that this is best done by cutting ourselves off
> from other Smalltalks and other exciting Smalltalk tools.
> 
> If ducasse at iam.unibe.ch is proposing to give us a tool which will
> automatically convert XML parsers, fancy browsers, &c to the new
> interface, well and good, the objection goes away.
> 
> Put it this way:  I would regard it as a significant improvement to
> C if 010 meant ten, not eight.  While I am more than capable of writing
> my own preprocessor to fix this, or of patching the three compilers I
> have sources for, doing so would actually lock me *out* of using tools
> which have *higher* payoff for improving my code.
> 
> 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.
> 
> SqueakMap doesn't show me a version of the Refactoring Browser that I
> can load and use.  There is a SmallLint *tutorial*, but no SmallLint
> *package*.  This is ironic, because this is the tool that could help
> people with #initialize bugs AND OTHERS without any kernel change at all.
> By flicking switches, I can see a version that says it might work in 3.4,
> but of course I'm not using 3.4.  Try it, .... "MessageNotUnderstood:
> hasPrimitiveChangeClassTo:".  Nope.  I _can't_ use RB.
> 
> Does anyone have a version of the Refactoring browser/of SmallLint
> that works in 3.5-5180 or 3.6 final?
> 
> 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.
> 
> 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.  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.



More information about the Squeak-dev mailing list