I've not yet read a clear argument for or against valof - I think a more
balanced approach is needed:
I see valof as being in much the same category as goto: its not exactly 'evil'
and there are some cases where it is OK (I won't elaborate), but in most
cases it can and should be avoided.
The drawbacks of using valof, and especially of computed valof's, e.g.
valof("ved" <> terminal_type)
are:
1) it can make it difficult to determine interdependencies in code.
2) there is a small performance and space overhead - you must keep the Pop
dictionary entry for the word around, and valof is slower than idval.
3) it may make code harder to read, test, maintain and debug.
Point (1), in conjunction with autoloading, is particularly problematic
when you wish to 'deliver' a Pop application - where by deliver I mean
produce a system which takes up the smallest amount of resources (disk
space, memory, process size, etc) whilst still containing everything
that the application requires to run.
Its interesting to note that to make valof to work with POPC (the
Pop-11 batch compiler) you should declare your interests (i.e. what words
valof will be called on) by using the uses-by_name construct, e.g. at the
top of the file you do:
uses-by_name vedsunxterm vedhpxterm vedvt220term ... ;
then your code can contain:
...
apply(valof("vedsunxterm"));
...
I think this is very good practice, as it makes quite explicit what the
interdependencies are.
Jon
|