On 9-Dec-2008, at 11:26 AM, Tim Johnson wrote:
On Dec 8, 2008, at 8:56 PM, Greg A. Woods; Planix, Inc. wrote:
Initially though this recommendation didn't make any sense to me
because I didn't know how the implementation of #new in Behaviour
is different from strict Smalltalk-80 as I understand it. I.e.
originally in Smalltalk-80 #new did not also send #initialize, but
now in Squeak it does.
This recent (!) change to auto-initialize puzzles me as well. So
much existing code was written with the opposite case being true,
that it seems so risky to change! To diverge from the ST-80
standard is even more risky, I would think.
Well what really angers me about this change is that it's not properly
documented in any way shape or form. There's just the code, and even
with all the code browsing tools in Squeak it still took me far longer
than it should have to figure this out. Part of that was my
unfamiliarity with Behaviour and ProtoObject, but most of it was the
total and complete lack of documentation about this difference. Even
outside the image itself there's just one very out-of-date page on the
swiki about this, and it gives no details or proper rationalization
whatsoever, and indeed it gives caution to some of the issues. It
certainly doesn't say it's a done deal -- in fact it's still in the
"improving" section. There's a very long and convoluted thread in the
mailing list archives but as yet I haven't even read anywhere of any
true consensus being reached (though many folks just seem to have been
beaten into submission).
I am annoyed that anyone would want to change this fundamental little
part of the basic Object protocol too. #new is supposed to answer a
new instance of the receiver. Period. Not also do any callbacks back
to any other instance methods. None. RTFM. Maintaining the status
quo is very important when you're talking about fundamental parts of
the object protocol. Now Squeak documents Behaviour>>new as returning
a new _initialized_ instance, but that's not (universally) true so
it's very confusing.
Now every book, every paper, every web page, including tons of
"squeak.org" web pages, are now (still) incompatible with the current
(and previous) release of Squeak. Squeak is now incompatible with its
own earlier versions. Squeak is now incompatible with code that used
to work in Squeak, and at least one of the classes right in the main
release, one which is used by a package still in the default package
universes, has been broken by a naive change (a relatively long time
ago) by someone who presumably should have known better (i.e. who was
probably aware of the change to #new) and who obviously didn't test
their change.
It seems to me that Squeak users _must_ now be experienced developers
in order to be able to file in old code and actually make it work in
far too many cases. I.e. this change is a total failure when it comes
to supporting _users_. If I had given out code that somehow relied on
the old #new protocol and then disappeared now only someone with
enough experience and knowledge can make use of it in a new Squeak
release. Indeed this happens all the time in the world of software,
all too often. But that doesn't mean it should happen. I'm beginning
to understand why many serious Smalltalk programmers I've met in
recent years consider Squeak to be no more than a toy.
I'm also beginning to understand why the gurus around me more than 20
years ago were telling me that default initialization was a "Bad
Thing(tm)". First off, not everything needs to be initialized. Also,
as was discussed in some detail before, this most basic form of
parameter-less initialization doesn't work for probably the majority
of classes which really do need initialization upon instantiation so
what exactly is the benefit anyway? Even the Blue book effectively
gives caution to why auto-initialization can be very tricky and far
less helpful than it may at first appear to be (p. 274).
Finally I think that some of the apparent justification for this
change, a topic that was bandied about on the mailing list way back
when, is also naive in and of itself. I'm referring to the claim that
this change will help educators avoid having to deal with the meta-
level of how classes are implemented. Don't get me wrong though --
I've never taught Smalltalk, this is just from my experience of
(trying to) learning it. First off I think the problem with the
concept of metaclasses in Smalltalk is that they're not exposed
clearly and plainly enough in the first place. The chapter(s)
describing them in sufficient detail comes far too late in all the
textbooks (especially the original one -- #16!?!?!?!). The default
code browsers have never been easily shown metaclass information in
any decent way that properly lays out the structure and hierarchy of
metaclasses a
