On Thursday 23 August 2001 06:48, Henrik Gedenryd wrote:
> Thanks Jecel,
>
> these are all very informative comments. I don't want to start a
> flame war and I know you like Self (ok, an understatement perhaps),
> but neither of the three issues is an uncontestably perfect solution.

Just to make my position clear: I like many languages and use different 
ones for different applications. For the kind of application I spend 
most of my time developing (interactive and media rich) I strongly 
prefer Smalltalk. Some of the other Smalltalks I have used, like 
Smalltalk Express (ex V/Win), are pretty similar to Squeak while 
others, like Self, are a bit more different. Other Smalltalks I have 
studied, such as Smalltalk-72 and MIT ConcurrentSmalltalk, are far more 
different.

There are many good points in all of them, and it is impossible to 
label the differences as "better" or "worse" since so much depends on 
one's taste. The point of this thread is to let each person decide what 
they like best, and for that they must be aware of what options exist.

> Jecel Assumpcao Jr wrote:
> > But having used the "implicit self" trick in NeoLogo as well as
> > Self and variations, I can say it is much more readable than what
> > you might think from a first impression. It does make a missing
> > statement separator (".") harder to spot since it becomes a run
> > time error instead of being  flagged by the compiler as in
> > Smalltalk.
>
> It seems this would mean that you cannot simply read the code to see
> that it is syntactically correct either (since its correctness is not
> a static property). Unless you take clues from line breaks and such.
> But in all fairness some ST syntax mistakes slip through the compiler
> in much the same way.

It is a slight difference. Compare the Squeak

   | temp  c |
   c := Color new named: 'red' "."
   temp := 3.
   ...

with the same thing in Self

  | temp. c |
  c: color copy named: 'red' "."
  temp: 3.
  ...

Squeak complains about "temp" being a new selector and you can easily 
notice the missing ".". If we had used the name of an existing 
selector, "copy" for example, then Squeak would have inserted an error 
message before the ":= 3." saying "nothing more expected".

In Self, this will compile with no problems and then try to send 
"temp:" to the string 'red', probably resulting in a "message not 
understood" error.

> > Exactly. If you write "self temp: value" it will work for "instance
> > variables" but fail for "temporaries".
>
> But this is unfortunately still inconsistent, the implicit receiver
> is sometimes self, sometimes "thisContext".

Not quite - the implicit self is always "thisContext", while the 
explicit self (as in my example) is always "self".

> Since the context is seen as an extension of the object (the context
> has the object in a parent* slot), I thought the simple solution
> would be to simply consider (the implicit) self to be this "extended"
> version of the receiver object.

That is exactly it. The explicit self I used in my example has not been 
extended with the local temporaries, but it obviously still has the 
instance variables. The implicit self has both.

> > x: y between: 0 And: z min: 255
>
> Whoa. Less parentheses yes. More readable?

You can put in the parentheses if you like. Anyway, it is hard to tell 
what is readable or not from a first impression. I have seen many 
novice C programmers start out with

#define BEGIN {
#define END }
#define AND &&
#define OR ||

Does this make C more readable? It does to them. I find the "graphic" 
characters break up the text nicely and make quickly scanning the 
source easier.

> Hmm. Also, making the
> parsing be sensitive to the capitalization of selector substrings is
> an "unorthodox" approach to say the least.

Would it be so bad to have "Class" mean one thing and "class" another? 
;-)

Sorry - I couldn't resist.

> And parens help the eyes to segment things.

Indeed. In fact, Dan's proposal for a more readable syntax was to 
replace colons with parenthesis, remember?

Note that I am just explaining how things are and why they were done 
this way, not giving my opinion on their merits.

> Another problem with the automatic accessors instead of assignment is
> that you can't protect state from outside access and modification
> (unless you add other mechanisms for hiding methods from the
> outside). There was some feature of that kind in early versions IIRC?

Yes - Self 1 and 2 had "privacy declarations" for slots. Since Self 3 
the virtual machine has simply ignored them and all slots are 
effectively public because this proved to complicate lookup too much 
for the programmers to follow. The idea was to put privacy back in once 
something better was designed. That would be the "viewpoints" in the Us 
language (which is a small, but very significant patch to Self).

> In all, weighing the pros and cons of the syntax changes doesn't as
> obviously come out in Self's favor as one first thinks. But of course
> it is in the skill of an author to present any feature to its best
> advantage, letting the downsides slip in the editing process ;)

It depends much more on the taste of the reader. See the threads on 
making Squeak more like Python or on having a "nicer" array access 
syntax.

-- Jecel