Constructors (was: RE: About KCP and automatic initialize)

Andreas Raab andreas.raab at gmx.de
Wed Sep 17 09:58:07 UTC 2003


[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 - 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).

> Also, it is a language change that fixes initialization, but is very
> inconsistent with many  other things about Smalltalk.

I agree.

> 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. 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.

> 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.

> 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.

> 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.

Yes, but they would be totally inadequate from a UI point of view.
Annotations (the way I used them) are a _workaround_ for not having any
other proper representation for certain attributes. Annotations are great as
long as you haven't figured out the UI for certain things, or if you want to
experiment with the semantics rather than the syntax, or if you don't care
at all. But I would refuse to apply this kind of annotation syntax for a
long-term solution.

So for figuring out the semantics using this annotation syntax is fine. In
fact, the annotation can even be used to represent the attribute long-term.
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!

Cheers,
  - Andreas

PS. Yay! After almost then years of Squeak we are finally starting to talk
about the interesting aspects.



More information about the Squeak-dev mailing list