Andreas Raab <andreas.raab at gmx.de> wrote:
> [Giving this thread a new subject]
> 
> Daniel wrote:
> > 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.
> 
> Um... first of all I didn't mean _that_ proposal seriously 
Seemed that way to me, but once someone starts treating it seriously,
its hard to avoid replying in kind.

> - in fact I made
> it deliberately obscure (by using "+" instead of something reasonable) so
> that the point of language change is more easily observable. I think there
> are much better and easier things that could be done if such a change were
> of interest (which it apparently is - much to my surprise).
>From my own perspective - for the issue of initialization only, I'd
prefer the status quo to the breakage that will result. If the prize is
bigger, the bearable pain might be too.

> > I would much prefer a change which is more consistent with the
> > spirit of the language, and much more powerful.
> 
> I'm somewhat sceptical about "much more powerful" solutions in this context.
> It leads easily to inventing "yet another meta layer" which is too powerful
> to be of use.
That is a risk of inventing powerful features, I agree. But OTOH, I
prefer the to make LISP style mistakes than PL/I style mistakes. As Stef
mentioned, while discussing language changes, we need to be very patient
and careful. There are many more different ways to get it wrong than
right.

> In this concrete case the situation is that we'd want to
> "flag" constructors in some way. That seems enough of a task for now not to
> have it overloaded with lots of additional semantics regardless of how
> powerful they are.
Sure, but adding a mechanism that addresses only one task means that
soon you'll have lots of new mechanisms.

> > 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.
> 
> That's correct - the Smalltalk tools assume this. After such a change Squeak
> would no longer be 100% Smalltalk 80 (tm) compatible. And accordingly, the
> tools would have to change.
It already isn't, and they already do. But this means
A. There will be a permanent cost in tool sharing.
B. We'd better make sure we have a clear model for the tools to use
before we start any changes (3.3a...). Derived methods are a big change
in this model, which might be a bigger issue than any syntax issues.

> > 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.
> Not necessarily. There are many things one can do - for example adding extra
> information to indicate whether the method has been manually edited or not,
> up to not even allowing to edit/see the method in the tools.
I'll tell you what worries me. The metaphor for "what code is" in a
system is IMO critical for people to feel at home in it. In C its a
bunch of files that get transformed. Awkward, but clear. In Scheme,
AFAICT, its a bunch of definitions that get interpreted and executed in
terms of one another (one can define new syntax for use in another). In
Smalltalk, code is a material that the environment executes and exposes
for shaping by the user. Code is always defined or modified by the user,
though some tools help him do so. This is a powerful model, because it
is pretty interactive and transparent. IMO, making parts of it derived
breaks some important assumptions in that simplicity.

I want to propose further tools/environment hacks that might alleviate 
some initialization problems without breaking the code model (modeled 
on our existing hacks to generate accessors) - 
1. A class-side DNU which looks up the message on the instance side, and
if an implementation is found in the initialize protocol, creates a
method that calls it. So if we define Point>>y:x:, then Point y: 5 x: 3
would DNU, find our method in the right category, and define Point
class>>
y: yValue x: xValue
	^self basicNew y: yValue x: xValue
2. A menu option for methods "make initializer" that generates the stub
described above on the class side.

The benefit of these proposals is that they provide a simple operation
newbies (and others) can do that lets them easily define a new
initialization scheme. This means that the meta class stuff is not
modified, but it can be more easily delayed until some more confidence
is gained. This, BTW, specifically doesn't deal with initialize, since the 
class side initialize and the instance side initialize mean different things.
But it makes it easier to create constructors that do get parameters.

[annotations ugly as UI, usable as tool for playing with semantics]
Haven't played with annotations enough to get annoyed at them. Does
create the interesting question of what semantics they should have, and
some potential for babel towers.

> But a proper UI solution needs to be found. Programming languages are user
> interface and you don't just stick a button into a list just because the
> list (being scrollable) has still room for it whereas the rest of your UI
> hasn't. The same applies here.
:-)
 
> > 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.
> 
> I'd be delighted to hear a proposal!
Well, I'd have to really *think* about that, you caught me totally off
guard ;-) In the mean time I'm curious to see what Nathanael has to
suggest.

Daniel