Self and Smalltalk (was: Need feedback on simple idea)
Jecel Assumpcao Jr
jecel at merlintec.com
Wed Apr 16 20:56:00 UTC 2003
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
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!
More information about the Squeak-dev