Compile Time Eval
Last published: April 16, 2008 by 'aknight'
Defines 0 Classes
Extends 1 Classes
An add-on to VisualWorks compiler, implements compile-timeevaluation construct, ##(expr) just as found in IBM Smalltalk and Dolphin Smalltalk.expr is evaluated at compilation time and the result is used as a literal object reference in place of the construct.
##(expr) is a `computable constant': expr is computed once during compilation, and stored as a constant. The actual invocations of the method later use that constant. This is similar to ##() syntax of Dolphin Smalltalk (and, of course, to `#.' reader macro of Common Lisp where it all began...).
Author: Vassili Bykov , July 13, 1996.
Anyone may freely use this for any purpose, provided that the copyright notice is preserved intact. This code is provided ``as is'', no warranties are given, and the author will not be responsible for any damage, no matter how awful, even if caused by defects in the code.
WHAT IT IS GOOD FOR
To avoid unnecessary computations of essentially constant expressions. For example,
foobar := 3 ** 20.
if written in a method text as
foobar := ##(3 ** 20).
will be compiled as if it were
foobar := 3486784401.
Another good example is something like
aChar = ##(Character tab) ifTrue: [...]
combining a nice readable method to specify an unreadable character constant, without introducing runtime penalty of an extra message send.
Other, more exotic, uses are also possible. For example, the following expression in a class initialization method would remember the day the class was filed in, or the date of the most recent recompilation, in a class variable:
MostRecentlyRecompiled := ##(Date today).
Later invocations of the methods would just reassign the same date to the variable (even though the date would be susceptible to the classical bug of literal constant mutability).
WHAT IT IS BAD FOR
1. To be used with expressions that are not essentially constant (unless capturing and preserving the current state is the primary goal, as in the timestamp example above).
2. Expression with side effects are probably not a good idea either.
3. When filing in, expressions referring to components of the same file-in may cause file-in errors, because the methods to handle the messages they send might have not been compiled yet.
1. Evaluation is performed in the context of the method's class. That is, if a method of Foobar class is compiled, self in the expression inside ##() would mean Foobar (the class)--it can't be the *real* method's self, of course!! But see the warning #3 above.
2. Any exceptions during evaluation are treated and reported as syntax errors.
3. Only one expression is accepted inside the parens, not a sequence. Since side-effecting would be a dubious practice, this is not much of a limitation."