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

Andreas Raab andreas.raab at gmx.de
Wed Sep 17 14:02:08 UTC 2003


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

Other systems have found pretty reasonable ways of dealing with it (or at
least so I think). For example, using a "layered" language approach could be
helpful. On a low level, there is a "kernel language" and on top of it sit
all of the added elements (syntactic or semantic sugar). Pretty much the
only thing one needs to make sure is that every program in the kernel
language is also a valid program (with the same semantics!) on the level
above.

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

It depends. This particular issue (namely how to initialize an object
correctly) is one which occurs every single time when I write a new class.
Knowledge about how to initialize an object is required every single time I
want to create a new object. It seems to me that we're talking about an
activity that is so widely used that it may very deserve its own
representation.

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

Yes. This is one of the prices you pay. There is no way around it.

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

Is that so? I guess it depends on how you look at it. How would you (in this
light) see inline compilations of, e.g., #to:do: or #ifTrue:ifFalse:
#ifNil:ifNotNil:? This is not what the user writes even if the system (by
implementing these messages) makes him think that it would be.

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

Yes, these assumptions are no longer valid then - in other words, we have a
different language, one that has different tradeoffs, rules, and further
assumptions. That's another one of the things that come along with a
language change. Changes in "what the user thinks" about what is happening
are inevitable - by the end of the day that's what _defines_ the language.

> 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

That's about the worst solution I can imagine. It would mean that whenever I
have a mistake in spelling a method I get a new initializer on the class
side. Even worse, I would imagine that this is being instantly abused. There
is _intent_ on the side of the person who is creating the last and the
constructor needs to recognize this intent.

> 2. A menu option for methods "make initializer" that 
> generates the stub described above on the class side.

The biggest complaint I have about this is that it's not descriptive. If we
want to defer exposure to the meta level for a while we need to be able to
_recognize_ constructors when we look at classes (e.g., is there an
initializer for PluggableListMorph?).

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

If they know about it. A "simple operation" is something that needs to be
seen in the context of the learning curve. Most people interested in a new
language are much more interested in the language than the tools - which
(although being stupid) should be recognized.

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

The UI problem with them is that they are in the wrong place. Visually, they
don't mark "the method" but rather "some place in the method" and that's
just very wrong. I would not expect that anything I see _in_ a method has an
effect _on_ the method. Note that is a consequence of abusing the
<primitive:> specification for which it makes perfect sense to think about
it as "in" a method.

Cheers,
  - Andreas



More information about the Squeak-dev mailing list