"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
> 	Also, it is a language change that fixes initialization, but is very
> 	inconsistent with many  other things about Smalltalk.
> 
> Would you care to elaborate?
Yes. Smalltalk doesn't have special precedence rules for arithmetic. It
doesn't have special syntax for specific control structures. It doesn't,
and shouldn't, have special syntax for instance creation. It's like
putting me in the goal keeper position of a world class soccer team -
everybody else would go home in utter despair :-)

> 	But Smalltalk tools also assume that a method source they can
> 	read is a method source they can change and recompile.
> 
> Would ensuring that the relevant tools *don't* believe they can
> read derived methods at least partly solve this?  We want the derived
> methods to have certain *code*, but the point of derived methods is that
> they are methods that people get without having to look at them.
> With the derived methods that have been mentioned so far, no bug can
> actually arise in a derived method, so even if the debugger just
> displays reconstructed source code and refuses to change it, that
> should be OK?
That would be a direction, but consider the trade off seriously - that's
a lot of added complexity to tools everywhere, that makes some of the
code feel dead and be less easily manipulated. This is a cost that might
be reasonable for a very general and powerful feature, but it is not a
reasonable cost merely for making initialization easier for beginner,
IMO.

> Nothing against method annotation.  Good idea.  But a derived method is
> a derived method.  How is deriving a method via an annotation any friendlier
> to existing tools than deriving a method via the compiler? 
Syntax is compatible. No rewriting of tools. Strange that you should ask
- that syntax change would break the RB, and I wouldn't do that
particular fix...

> And if the
> annotation is any heavier than "<new>", is it going to be as good for
> beginners as Andreas Raab's suggestion?
<shrug> Andreas believes not, I'll believe some reality testing on
students.

> Personally, I *like* putting instance creation methods on the class side.
[snip]

Me too. The question is what else does it drag in. I don't mind having
two levels, that the model I usually use. What I hate is that it is
wrong - there are multiple levels, and the instance-of and subclass-of
relations interact, and there are circularities... I'm curious how bad
things would be if by default, the class level and base level
inheritance weren't parallel.
So by default in anObjectSubclassInstance, self class superclass ~=
super class. 

To inherit class side behavior, one would explicitly reparent the class
side, independently of the instance side. How would that feel like? what
thought patterns would it break?

Daniel