Things you can do in Smalltalk

• Introduction
• Installing new Code without Downtime
• Reflecting on Object References
• Iterating over Private Variables
• Generating Code Dynamically
• Singletons
• Tracing, Counting
• Factory Pattern
• Powerful Exceptions
• Powerful Numeric Class Hierarchy
• Quining - A Program which Generates its own Source

Introduction

Many things which are difficult or even impossible to solve in other programming languages are simple or trivial in a highly reflective system such as Smalltalk. Many of the patterns as collected and described by the gang of four are not needed or are much simpler in Lisp or in Smalltalk.
This document will show some of this kind - it is not about things you can do in Smalltalk which you can also do in any other language, but about things which are very easily done in Smalltalk but drive you mad in other languages.
Even if you are already a smalltalker, it may also be interesting to read and to get new ideas.

Updates, Fixing without Downtime (24/7 operation)

    'patches' asFilename directoryContentsDo:[:eachFile |
	Smalltalk fileIn:eachFile
    ].

Reflecting on Object References

Smalltalk provides very powerful reflection and manipulation features on the object reference level. For example, it is possible to find all instances of a class:

    SomeClass allInstances

    SomeClass allSubInstances

    SomeClass allInstancesDo:[:inst | inst becomeNil]

    SomeClass
	allInstancesDo:[:inst |
	    (inst isOwnedBy:tabToBeClosed) ifTrue:[
		inst becomeNil]]

Iterating over Private Variables (i.e. Instance Variables)

In Common Lisp I have often wanted to iterate through the fields of a struct-- to comb out references to a deleted object, for example, or find fields that are uninitialized. I know the structs are just vectors underneath. And yet I can't write a general purpose function that I can call on any struct. I can only access the fields by name, because that's what a struct is supposed to mean.

In Smalltalk, you can access an object's slot via the "instVarAt:", "instVarAt:put:" and "instVarNamed:" messages. The names of the slots are retrieved with "allInstanceVariableNames", the number of slots via "instSize".

Thus, a debugging method to dump *ANY* object's contents could be:

    dump: someObject
	someObject class allInstanceVariableNames
	    doWithIndex:[:name :idx |
		Transcript
		    show:name;
		    show:' is ';
		    showCR:(someObject instVarAt:idx).
	    ]

    dumper :=
	[:someObject |
	    someObject class allInstanceVariableNames
		doWithIndex:[:name :idx |
		    Transcript
			show:name;
			show:' is ';
			showCR:(someObject instVarAt:idx).
		]
	].

    objectsDoBeDumped do:dumper

    dumper value:Transcript

Generating Code Dynamically

Dynamically generated Blocks

    |s b|

    s := '[:a :b | (a squared + b squared) sqrt ]'.
    b := (Block fromString:s).
    Transcript showCR:(b value:3 value:4)

You can (and should) analyze the code for the messages being sent, to make sure that no bad messages (i.e. only allowed ones) are introduced if the codestring originates from a user:

    |s b allMessages|

    s := '[:a :b | (a squared + b squared) sqrt ]'.
    b := (Block fromString:s).
    allMessages := b homeMethod literals.
    Transcript show:'block contains messages: '; showCR:allMessages.

    |s b codeString allowedMessages|

    allowedMessages := #( + - * / sqrt squared sin cos value ).
    codeString := Dialog request:'Give an expression on a and b.
Use parenthesis as in (a*5) + (b sin):'.
    codeString notEmptyOrNil ifTrue:[
	s := '[:a :b | ',codeString,']'.
	b := (Block fromString:s).
	((b homeMethod literals)
	    contains:[:msg |
		(allowedMessages includes:msg) not
	    ])
	ifTrue:[
	    Transcript showCR:'Sorry - the block contains a bad message'.
	] ifFalse:[
	    Transcript show:'The value of "',codeString,'" for a=4,b=5 is '; showCR:(b value:4 value:5).
	].
    ].

For check-code like the above, the builtin Parser or RBParser frameworks can be used. Then, reflect on the parseTree instead of either source- or byte-code.

Dynamically generated Methods

    Number
	compile:'cubed ^ self * self * self'

    5 cubed

    5.0 cubed

    Number removeSelector:#cubed

Dynamically generated Classes

    |cls|

    cls := Object
	      subclass:'anonymous'
	      instanceVariableNames:'firstName lastName'
	      classVariableNames:nil
	      poolDictionaries:nil
	      category:nil
	      inEnvironment:nil.
    cls compile:'firstName ^firstName'.
    cls compile:'firstName:s firstName := s'.
    cls compile:'lastName ^lastName'.
    cls compile:'lastName:s lastName := s'.

    ((cls new firstName:'hello') lastName:'world') inspect.

Dynamically generating Code without affecting the ChangeFile/ChangeList

    Class withoutUpdatingChangesDo:[
	...
	cls compile:'...'
	...
    ].

Singletons

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

Tracing, Counting, Limiting the Number of Instances

    newCounted
	instanceCount := instanceCount + 1.
	^ self new

Factory is not needed

    controller
	^ self controllerClass new

    controllerClass
	^ VeryStrictController

    controllerClass
	(Time now hour between:18 and:20) ifTrue:[
	    ^ FriendlyControllerForHappyHour
	].
	^ super controllerClass

The advantage of being a fully dynamically typed language ensures that this code even works unchanged in ten years, when fifty new classes and subclasses for controlling have been added in various parts of a bigger system.

Powerful Exception Handling

Some have argued "why would one want to proceed after a raise" - but that's the typical "I am a hammer - everything must be a nail" attitude - or in other words: "if all I can use raising for is to signal non-proceedable hard error situations, why would I want to proceed after an exception?".

A more intelligent aproach is to see an exception as "something unexpected happened - can anyone help?". or even: "something unexpected happened - is anyone interested?".

If you look at exceptions from this perspective, it makes sense to send notifications, warnings, progress-information etc. all using the exception mechanism. For example, in Smalltalk/X, all info- and progress notifications are performed by raising a Notification.

Even more convenient is the situation if some object deep down in the calling hierarchy needs additional information to handle an unnormal situation. For example, a compiler might need to know if it is ok to compile code with ugly or old style code in it. If the compiler is executed in the interactive IDE, and a user has originated the compile operation, it is convenient to open a little dialog window and ask the user. However, if the compilation is within a batch operation, and 3000 files are to be compiled, you better not ask the user for every method. In Smalltalk/X, a so called Query is used - this is a kind of exception which - if unhandled, proceeds with a default value, but can be handled and return a value as requested from the user. In all languages without proceedable exceptions, you would have to pass such information down either via arguments along every called function, or by setting global or other static flags, which will later make it hard to use the compiler in a multithreaded operation.

Powerful Numeric Class Hierarchy

If you compute values in a 32bit environment, you have to be very careful to not generate incorrect results. The situation is less of a problem with 64bit integers (but still present), However, it requires the programmer to always think about the consequences and never forget to write "long long" instead of "int". Programmers must also always know the value range of their integers - something which can be hard if you write a reusable library component, and you have no control over the incoming values. Another problem are rounding errors due to floating point arithmetic. A programmer has to always think not only about the type ("int", vs, "long", vs. "long long") but also the values of intermediate results.

To illustrate this, try to evaluate a trivial expression like "a / b * c" with a,b,c being integers. Without much thinking, you'd write in C:

    int a, b, b;

    ...
    result = a / b * c;
    ...

Now, how about "a=1", "b=2", "c=5" ?.

Every kid tells you: "well, the result is 5/2 (or 2.5, if you like).
But not so the advanced programmer; he'd say: "well, in theory. But in the real world, the result is zero, because of integer truncation". Programmers tend to "make virtues out of necessities" and blame themself for obvious deficiencies of the language system. Real programmers know their system's limitations. BTW, the situation is not better in the C++, Java and C# world.

Let us continue for our amusement; you might think about how to fix this and write:

    int a, b, b;

    ...
    result = (int)((float)a / (float)b * c);
    ...

Surprise, surprise: we get "100000000". Well, fair enough; who cares for that little error. Who cares for that lost penny - simply transfer it to my account (yeah, that's what banks do usually) !

Ok, you say, lets get rid of the rounding error, and go back to integer code. To avoid the truncation, let's multiply first:

    int a, b, b;

    ...
    result = a * c / b;
    ...

Wow, 277 !

The problem with these languages is that the code looks ok, but computes something radically different from what you read. The operation which is performed in the above code is actually:

    result = trunc( (int)(unsigned(a * c) mod 4294967295) / b);

Conclusion: without a proper numeric class hierarchy, it is VERY difficult (but not impossible) to write mathematical correct computations.

Finally, for your amusement: Quining - A Program which Generates its own Source

|a| a := '[:a | Transcript show:''|a| a := '';showCR:a storeString,''.'';showCR:''(Block readFrom:a) value:a'' ]'.
(Block readFrom:a) value:a

Copyright © 2007-2009 eXept Software AG, all rights reserved