Daniel Vainsencher <danielv at netvision.net.il> wrote:
> Also, it is a language change that fixes initialization, but is very
> inconsistent with many  other things about Smalltalk. I would much
> prefer a change which is more consistent with the spirit of the
> language, and much more powerful.

Myself as well.  I hate to be the voice of "eating Smalltalk's young",
but imagine trying to explain this to new Smalltalkers.  One of the nice
things about using Squeak in a classroom--one that the students rarely
catch on to--is that they spend proportionally very little time learning
the language.

Perhaps neither method of initialization is particularly fast to learn. 
Let me tell you, students definitely have trouble learning to make #new
return an initialized object.  So the construct alone is not a horribly
big deal.

However, there are other learning issues at stake.

First, students already have a hard time with class methods versus
instance methods.  Blurring the line in this one case should make the
distinction harder to understand.

Second, students have a hard time getting the idea that everything is an
object and that all interactions happen via message sends.  Having
automatic methods popping up makes it slightly harder to get this Big
Idea -- and big ideas are one of the main reasons Squeak shows up in the
curriculum.

The prototypes idea some people are batting around does not have these
problems.  With the prototypes idea, you deal with regular old messages
like #prototype and #initializePrototype and you get extra reinforcement
of the messages idea.

Finally, an interesting educational bonus of any of these initialization
approaches is that you avoid needing class methods for the most common
cases.  If initialization didn't require class methods, then maybe
students could make it through the whole semester without having to
touch them.  That would free up an hour or two of class time and think
time that could be used for something more beneficial.


-Lex