Just thought I'd note that Andreas suggestion is quite likely to break
the RBParser in two ways - at the syntax level (+ isn't a legal first
character in a selector), and at the semantic level, because the RB
doesn't know about derived methods, and it will happily let you make
local changes to one of two methods that should remain synchronized.

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. Note that the "derived methods" issue
can be dealt with, but it isn't trivial. If we have derived methods
observe their sources and change automatically, we solve the surface
issue. But Smalltalk tools also assume that a method source they can
read is a method source they can change and recompile. This is true
about the Browser variants, but also about the RB as an automated
rewriting tool. I think the core issue here is that derived methods and
Smalltalk don't really fit.

Lets talk about alternatives -
1. Avi proposed method annotations as a general syntax that would allow,
among things the implementation of derived methods along these lines.
These have the benefit of compatibility with VW, at least. Also they are
powerful enough to solve problems other than initialization, so we won't
be talking about another change quite as soon.
2. IIRC, Alan Kay once mentioned that he didn't particularly like the
Metaclass solution to the initialization problem. I agree, and if that's
really all that metaclasses are really needed for, I think we should
seriously consider alternatives that are simpler. We might end up
breaking compatibility on a wider scale, but at least we have a chance
to end up with something that's simpler on the whole.

Daniel

"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
> In contrast, Andreas Raab's proposal has _no_ unhappy consequences for
> any existing class (other than the classes that have to be changed to
> implement it), and it deals with _all_ kinds of creation, not just
> parameterless creation.