Smalltalk for Java/JavaScript Guys

Introduction

Please try to understand them.
It may even be interesting to read, if you are a smalltalker !

Syntax - So you can read Smalltalk Code

Variables

The variable is untyped - it can hold a reference to any object. However, the object itself "knows" what it is. It knows the class of which it is an instance. Smalltalk is a dynamic strong typed language, in contrast to e.g. C, which is a static weak typed language.
This is very similar to how JavaScript deals with variables and types.

Local Variables

    var foo, bar, baz;
    var a, b, c;

    |foo bar baz a b c|

The Current Receiver: "self" vs. "this"

In Smalltalk, the pseudo variable "self" refers to this object. In Java/JavaScript, this is called "this".

As Smalltalk classes are also instances of some (meta-) class, the above also holds if a class method is called for (i.e. if a message is sent to a class object). There, "self" refers to the receiving class.

There is no corresponance to this in Java. Even if static functions might look like similar to Smalltalk's class methods, they are not: in Smalltalk, class methods can be redefined in subclasses just like other ordinary instance methods, and the class method sees the current receiver as "self".

Inside a block (the "inner function"), "self" refers to the receiver of the method in which the block was defined. Thus blocks are actually closures and behave much like inner functions in JavaScript (or lambdas in new Java).

Statements

So, the javaScript:

    <statement1> ;
    <statement2> ;
    <statement3> ;

    <statement1> .
    <statement2> .
    <statement3> .

The semicolon has a meaning in Smalltalk, which is described below.

Assignments

In Smalltalk, to avoid confusion with the equality comparison operators, assignment is written as ":=", whereas in Java/JavaScript, you would simply write "=".
So:

    var a, b, c;

    ...
    a = 5;
    b = 4;
    c = a;
    ...

    |a b c|
    ...
    a := 5.
    b := 4.
    c := a.
    ...

Returning a Value from a Mehod

    ...
    return ( <someExpression> );
    ...

    ...
    ^ <someExpression>.
    ...

In Smalltalk, a method return always returns a value from the currently executing method. Even if that return is inside an inner block, which is described below.

Message Sends (Virtual Function Calls)

Every such message send invokes a function (called "method" in Smalltalk) of the "receiving" object; it is the receiver's class, which determines which method will actually be executed. That is almost the same behavior for all three languages.

The syntax is slightly different:

Unary Messages (no argument passed)

    receiver.foo();

    receiver foo.

    var a, b, c;

    ...
    a = b.abs();
    c = a.foo();
    b = a.foo().bar().baz();
    ...

    |a b c|
    ...
    a := b abs.
    c := a foo.
    b := a foo bar baz.
    ...

Keyword Messages (arguments passed)

The name of that function is actually the concatenation of multiple parts, including the colon(s), to distinguish it from the above unary messages. In Smalltalk, every function which expects an argument must have colons in its name (one for each argument). Thus, the number and position of the arguments is fixed and defined by the function's name. So, a call to a "fooBar" function, with 2 arguments,

    var a, b, c;

    ...
    a = b.fooBar(1, 2);
    c = a.fooBarBaz(1, 2, a);
    ...

    |a b c|
    ...
    a := b foo:1 bar:2.
    c := a foo:1 bar:2 baz:a.
    ...

Notice, that it is possible in JavaScript, to call a function with a wrong number of arguments:

    var a, b, c;

    ...
    a = b.fooBar(1);
    c = b.fooBar(1, 2, 3);
    ...

Sometimes, especially when code is generated automatically from Java/JavaScript like languages, methods use a single underscore character to separate arguments, as in:

    x.someGeneratedName:arg1 _:arg2 _:arg3.

Also notice that in Smalltalk, "foo:bar:" is a different message name than "bar:foo:", and that these will invoke different methods. There is no "automatic reordering" of message arguments and no "automatic renaming" of message names.

Binary Messages

    (x add:1) mul:5.

Especially, the language does not imply any arithmetic meaning and the compiler treats all such messages the same. Therefore, no precedence or grouping as in Java/Javascript is associated to those. They are simply evaluated from left to right.
That may make mathematical expressions hard to read, as you have to use parenthesis for grouping (and you often should, even in case the left-to-right order is the desired one).

So, the Java expression:

    a + b * 5 + 4

    a + (b * 5) + 4

This may be a bit confusing or annoying for beginners. Experienced Smalltalkers use parenthesis and don't even think about it. Actually, making the evaluation order explicit using parenthesis is considered good style anyway - even in C, Java or JavaScript: you don't have to think if the shift operator has precedence over a comparison or not.

Notice that not only "+", "-", "*" and the other arithmetic operators are allowed as binary message names. Almost any other non-letter can be used, and even multi-character combinations are allowed (the original Smalltalk-80 version did not explicitly define a limit on the number of characters, but actually limited this to a max. of 2. Modern Smalltalk implementations usually allow up to 3).

Now you understand the meaning of the comma-operator ",": it is a binary message implemented in many collection classes which creates a concatenation of the receiver and the argument. So 'hello','world' creates a new string containing 'helloworld', and because it groups left to right, you can create longer strings as in 'hello',' ',(OperatingSystem getLoginName).

Semicolon - Sending Multiple Messages to the Same Receiver

    var t = new Executor;

    t doThis();
    t doThat(someArg);
    t doSomethingElseWith(arg2, arg3);
    ...

    |t|

    t := Executor new.
    t doThis.
    t doThat:someArg.
    t doSomethingElse:arg2 with:arg3.
    ...

    (Executor new)
	doThis;
	doThat:someArg;
	doSomethingElse:arg2 with:arg3.
    ...

Such constructs are called "cascaded messages", and the value if the cascade is the value returned by the last cascaded message send. So you have to be a little careful, when assigning the value of a cascade, as in:

    e := (Executor new)
	    doThis;
	    doThat:someArg;
	    doSomethingElse:arg2 with:arg3.
    ...

    e := (Executor new)
	    doThis;
	    doThat:someArg;
	    doSomethingElse:arg2 with:arg3;
	    yourself
    ...

Anonymous (inner) Functions

    myBlock := [ a foo. b bar ].

    myFunc = function () { a.foo(); return b.bar(); };

    |m1 m2 outerBlock|

    m1 := 1233.
    outerBlock :=
	[
	    |o1 o2 innerBlock|

	    o1 := 1.
	    o2 := m1 + 1.
	    innerBlock :=
		[
		    |i1 i2|

		    i1 := o2 + m1 + 4.
		    [ i1 + 1 ]
		].
	    innerBlock
	].

    var m1, m2, outerFunc;

    m1 = 1233;
    outerFunc = function() {
	    var o1, o2, innerFunc;

	    o1 = 1;
	    o2 = m1 + 1;
	    innerFunc = function() {
		    var i1, i2;

		    i1 = o2 + m1 + 4;
		    return function() { i1 + 1; };
		};
	    return innerFunc;
    };

If a block gets evaluated, its inner statemens are evaluated, and the block's return value is the last inner statement's expression-value. So, inside a Smalltalk block, there is no return-from-this-block-statement, only expressions which are evaluated in sequence, for the last one to provide the return value of the block. You can (and often will) put a return inside a block, but it has a completely different behavior and is described below in more detail.

Blocks can have arguments, these are listed at the beginning, each with a trailing colon, before a vertical bar, as in:

    |block1 block2 block3|

    block1 := [ self helloWorld ].
    block2 := [:arg1 | self helloWorld ].
    block3 := [:arg1 :arg2 :arg3 | self helloWorld ].

    |myCollection|

    myCollection := #(1 2 3 4 5).
    ...
    myCollection do:[:el | Stdout show:el].
    ...

    var myCollection;

    myCollection = [1, 2, 3, 4, 5];.
    ...
    myCollection.forEach( function(el) { Stdout.show(el); };
    ...

Returning through a Block

    myMethod
	...
	someCollection do:[:el |
	    (aMatchBlock value:el) ifTrue:[^ el]
	].
	...

    function myMethod() {
	...
	someCollection.forEach( function(el) {
	    if (aMatchBlock(el)) return el from myMethod;
	}
	...

    function myMethod() {
	...
	forEach( el in someCollection) {
	    if (aMatchBlock(el)) return el from myMethod;
	}
	...

If you think carefully, you'll see that it does not really make sense to return from the block alone in the above enumeration code, as this would simply leave the inner block, and continue enumeration with the next element.

If at all, it sometimes makes sense to break out the whole enumeration loop. For this, Smalltalk collection classes offer an additional enumerator called "doWithExit:". This passes an additional "exit"-argument to the block:

    ...
    someCollection doWithExit:[:element :exit |
	...
	someCondition ifTrue:[ exit value ]
	...
    ].
    ...

    ...
    forEach (el in someCollection) {
	...
	if (someCondition) break;
	...
    }
    ...

Try / Catch / Finally

    try {
	...
	some computation
    } catch(<someErrorClass> e) {
	...
	handler action
	...
    } finally {
	...
	cleanup
	...
    }

    [
	...
	some computation
	...
    ] on:<someErrorClass> do:[:e |
	...
	handler action
	...
    ] ensure:[
	...
	cleanup
	...
    ]

In both cases, "someErrorClass" is the class of the error to handle, and "e" is object providing exception information details. Also, in both languages, the Exception class forms a hierarchy, and a handler for an exception class E will also catch exceptions for any of its subclasses.

In addition to this hierarchical organisation, Smalltalk also offers handler sets, which catch a bunch of possibly unrelated error types. For example, to catch both arithmetic and file-operation errors in a single handler. And, another useful feature are ad-hoc exceptions (called "Signal"), which do not need a class, but are created "on-the-fly" and allow for purely private, completely anonymous exceptions, queries and notifications.

Semantic Differences

This subtle difference has many implications:

• Smalltalk exceptions can be proceeded
  a handler may cleanup the situation and proceed. For example, a file-not-found exception could be cought, a dialog opened in the handler asking for a replacement file, and the handler could proceed execution passing an alternative filename or stream as return value from the raise.

• a debugger can show life values
  in Smalltalk, there is always a default fallback handler active (i.e. even if your code does not contain a handler, there is always another one around in an outer scope). This default handler opens a symbolic debugger on the suspended execution. As all local variables, arguments and other execution state is still alive, the debugger allows for very easy inspection of the program's state. There is no need to prime exceptions (i.e. tell the systems, which exceptions are to be debugged) for being debuggable in advance.

• a debugger can proceed after fixing
  the proceedability allows for even more fancy things to be done in the debugger: you can change/fix any invalid code right in the suspended state and proceed the suspended execution. Or restart any of the active methods in the suspended calling chain from the beginning, or simulate a return from any of them.

• proceedable exceptions are a synonym for notifications
  you can also use proceedable exceptions to tell an outer caller about ongoing activity. For example, info messages, logging, progress information and other such UI-related stuff can be sent out from an inner processing function by raising a notification (which is a subclass of exception, but always proceedable, and - auto-proceeds if no handler is present). Thus, if some method is interested in such notifications, it can simply provide a handler. If no handler is present, the notification is ignored. This is a great way to pass compiler, parser, file-reader and other warnings to whomever it may concern.

Handler Sets

    [
	...
	some computation
	...
    ] on:OpenError, ArithmeticError do:[:e |
	...
	handler action
	...
    ]

    (ExceptionHandlerSet new)
	on:ZeroDivide    do:[:ex | 'division by zero' printCR. ex proceed];
	on:HaltInterrupt do:[:ex | 'halt encountered ' printCR. ex proceed];
	on:DomainError   do:[:ex | 'domain error  ' printCR. ex proceed];
	handleDo:[
	    ...
	    your code here
	    ...
	]

Classes are Objects, too!

In Smalltalk, classes can be passed as argument, returned as result, stored in variables, etc. Everything that can be done with regular objects can also be done with classes.

One major effect of this, is that makes many design patterns which deal with factories, facades etc. obsolete in Smalltalk. For example, to instanciate either a FileLogger or a DummyLogger, depending on some condition, you'd simply write:

    logger := (debugging ifTrue:[FileLogger] ifFalse:[DummyLogger]) new.

Or you can pass a class as parameter:

    makeLogger:whichLoggerClass
	^ whichLoggerClass new

The instance creation method "new" is therefore a regular class method, which can be redefined in a subclass. And the subclass may do something completely different in its own new method. For example, a singleton class may want to redefine new, to ensure that only one single instance of it is ever instantiated, by redefining new as:

    new
	TheOneAndOnlyInstance isNil ifTrue:[
	    TheOneAndOnlyInstance := super new
	].
	^ TheOneAndOnlyInstance

Another example is a class which redefines "new" to count the number of instantiated instances:

    new
	Count := Count + 1.
	^ super new

Having redefinable class protocol makes another big part of the design patterns obsolete. After all, some (cynic) tongues say that after all, "most design patterns are workarounds for bad language design".

Class Instance Variables vs. Class Variables

Class Variables have a global scope, but are only visible in the class and its subclasses. A class variable exists exactly once, and all references to it refer to the same binding.

Class Instance Variables are additional private slots in the class object, and inherited by subclasses. However, each subclass gets its own binding slot. Thus, Class Instance Variables are for the class, what "private variables" (Instance Variables) are for regular objects. The code to work on them is shared by a class and its subclasses, but each class may have a different value for it.

In the above Count-example, if "Count" was a class variable, it would exist exactly once, and count the number of instantiations of the class and all of its subclasses.

In contrast, if "Count" was a class instance variable, the class and each subclass would have a private counter, which counted the number of instantiations for each class separately.

Class instance variables are very useful to provide per class caches, configurations etc. which have a similar functionality, but require different state as per subclass.

There is no corresponding mechanism in Java, and actually it would be harder to simulate. An implementation might use a HashTable, using a combination of (sub-)class and variable name as index.

Shared Pool Variables

Thus, they can be seen as static variables, with a restricted visibility among multiple classes which need not be subclasses from a common superclass. (in Java, a static variable can never by seen by an outside class).

The Class Library

Number Classes

Mixed mode arithmetic is provided, and operations return a result as appropriate for the operands.

Smalltalk automatically cares for out-of-range values, and returns exact results for integer and fractional arithmetic (i.e. when adding two integers, it checks the result and automatically converts the result to a LargeInteger (which is Smalltalk's equivalent of BigInteger).

Integer overflows are not possible in Smalltalk.

In Smalltalk, all numeric objects are real objects (with a class, which can be extended to provide additional methods). As a Java programmer, think of all numbers being always boxed. In Smalltalk, there is no such concept as a native type, and every number is a full-blown object which can be put into containers, passed as argument or returned as value without special declarations.

Collections

A little annoying in Java is the different syntax and protocols of primitive type arrays vs. object collections: length vs. length() vs. size() and "[]" vs ".get()" and ".put()".
In Smalltalk, all getters are named "at:", all setters are named "at:put:" and to get the size of a container, always use "size".

With the exception of a few special collections (ByteArray, IntegerArray and FloatArray), all collections can hold any object in Smalltalk. There is no need/support for generics or templates. However, as all collections can be subclassed or wrapped, it is possible to define typed collection classes, which may restrict the set of accepted element types.

The above mentioned exceptions (ByteArray,...) are space-efficient variations.
For example, ByteArray stores byte-valued integer objects and needs 1byte of storage per element. In contrast, a full blown Array instance would require one pointer (4 or 8bytes, depending on the CPU) per element.
A similar "space" efficient container is "String" (which stores 1-byte characters), "Unicode16String" (which stores 2-byte characters), "FloatArray" and a bunch of other classes (IntegerArray, WordArray, DoubleArray etc.)

Streams

Open vs. Closed Class Librariy

In practice, this has resulted in a lot of duplicate code in typical Java projects. You will often find utility container classes which duplicate existing functionality only because the original class cannot be extended.

For bigger projects, this shows up in the number of classes and methods (and lines of code); Java projects usually require many more lines of code than corresponding Smalltalk projects (we have seen Java projects which take up 5 times as many classes as the corresponding Smalltalk code).

Be prepared for more to come on reflection, the class library, extensions etc.

Copyright © 2002 Claus Gittinger, all rights reserved