Conquest 1.0 alpha available
Andrew C. Greenberg
werdna at gate.net
Sun Dec 19 20:23:20 UTC 1999
>I sent an email but nobody reacted but I still want to raise the
>following issue: automatic initialization of instances.
I saw three messages.
>Why Behavior>>new does not call automatically Object>>initialize (or
>others specialized ones)?
*snip*
>I wrote the following stupid finder and found in the Squeak2.6 image 60
>occurences of new ^ super new initialize
Perhaps its because this "solution" isn't general enough. Have you
considered that 60 classes using the method you describe means that
there are several hundred that do not -- or have inherited what they
need already?
In particular, many classes REQUIRE parameters to know how to
properly initialize instances. Some (not enough) override new to
alert unwary users from doing so.
I am not suggesting that the "convenience" of an automatic call to a
default #initialize might not be useful, but it WOULD trade the time
of additional message sends for EVERY INSTANCE CREATION IN THE
SYSTEM, for mere "convenience." In practice, after few weeks of
coding (and a quick read of Ralph Johnson's "top ten bugs"), I never
made the mistake of failing to write the initialization code, learned
the idioms for those classes for which it is straightforward, and
learned from the blue book how to handle the cases for which it is
not. Any savings in text and code is TRIVIAL compared to the costs
of requiring every class to go through your empty initialization
message send, particularly if the standard initialization (all nil)
is satisfactory.
The pedagogical advantage claimed is also something of a canard.
Users will still need to understand metaclasses in order to deal with
objects for which the #initialize protocol is insufficient. In
short, Smalltalk is not CLOS, and I'm not sure that losing the
ability to define arbitrary metaclass protocols is worthwhile. I for
one am not particularly willing to have to add to the instance side
of every such object a foundry-like protocol.
>Then I have the following suggestions
> - why basicNew is not called allocate because this is what is does?
>
> - then new could be really
> new (initialize(allocate))
And here's the really neat thing about Smalltalk. You can have it
your way! What's more, if it is useful, natural selection will lead
to its adoption. My suggestion, however, is that it would be far
more intelligent until your view is adopted that you adopt the new
terminology and implement it so things can live side by side, rather
than trying to supplant it with an experiment.
In particular, why not adopt
create
as your instance generator with automatic 0-adic initialization, and
allocate
as your instance allocator without initialization (identical to basicNew)?
This, we can have our new, basicNew, and metaclass confusion; while
your world does what you want. If the world is ready, and if your
paradigm is better, it will in time be adopted. If not, we all still
will have learned something.
BTW, I agree that allocate is better than "basicNew" in describing
what occurs in practice. However, it does not carry with it the
convention of being non-overridable.
More information about the Squeak-dev
mailing list
|