On Friday 11 April 2003 04:47, Stephane Ducasse wrote:
>  Can you explain me how local variable are declared in self? I always
>  wanted to know and forgot since I looke at self.
>  Can you show me a piece of code with a block defining a variable and
>  accessing it?

   | b |
   b: [ | :arg. local | local: arg+1. local*local ].
   b value: 10. "should return 121"
   b value: 3. "should return 16"

But local variables don't have to start out with nil:

   [ | :arg. local <- 10 | local * arg ] value: 3 "should return 30"

though in this particular case we could have declared local as a 
constant using "local = 10" (then there would be no #local: method).

I would like to comment on a very important discussion that is implied 
by what is being said in several threads: "what is the Matrix?"... 
er... I meant "what is Smalltalk?"

While I admit my definition of "language" is far broader than other 
people's, so that I consider Lisp/Scheme/Logo one language and 
Java/C#/Delphi another, that is not the only reason while I call Self a 
Smalltalk. Sure my definition of Smalltalk is broad enough to cover 
Smalltalk-72, FScript, Slate and so on. But Mario's Smalltalk 
"emulator" in Self proves that it is a unique case. Most people don't 
understand what he did: when you "file in" his package you get full GNU 
Smalltalk compatibility. You type in Smalltalk-80 sources and they run. 
You inspect objects and browse classes and everything works just as you 
would expect. The name "emulator" is unfortunate, for this is like 
Dan's alternate syntax and *not* like his Smalltalk-72 in Squeak. There 
aren't two levels, but two views into a single programming environment.

So you can create a method and an instance variable with the same name 
in this system, if you wish to do so. Having a simpler kernel does not 
mean abandoning all the old code. In fact, I would like to see more 
compatibility - "class = namespace" is not enough and doesn't allow me 
to file my Squeak 2.7 code into 3.0. What we have now is too brittle 
(not as bad as the "fragile base class" problem that plagued C++ 
efforts like BeOS).

So I want: simpler, more functional, more compatible. There are three 
ways you can get simplicity:

 1) add a layer abstracting the complexity away
 2) remove stuff you might not need
 3) understand a problem so deeply that you see a simpler solution that 
does more

Tk based interfaces to /etc configuration files in Unix is clearly an 
example of 1. ColorForth is mostly 2, with some 3 mixed in.

I sure don't want to see 1 happen to Squeak. Let's aim for 3!

-- Jecel