Jonathan Meyer (jonm@uk.co.integ) wrote:
> I've not yet read a clear argument for or against valof - I think a more
> balanced approach is needed:
Time for a less balanced approach, I see :-)
> 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.
And let's add to that list
4) it can make working with sections (pointlessly) difficult.
[Some of these objections may disappear when POPC emerges, of course.
I am really, really looking forward to POPC. I really (really) hope that
14.5 contains a version of it.]
> 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"));
> ...
It is also plain that "uses-by_name" could be replaced by entries
in a hash-table.
The summary position is: using valof entails a variety of
programming issues, some obvious and some subtle. Properties can be
used in place of -valof- without these complexities. The circumstances
under which it is satisfactory to use properties are (1) those in which you
are the only consumer of the code (2) when writing code which needs to
examine the current executing environment (e.g. symbolic debuggers).
Steve
|