[Richard Suchenwirth] 2002-05-21 - [Proc]s, our little helpers, that
we call (and most often also write) every day in Tcl, can have
interesting twists and turns - see [Procs as data structures], which may
contain no valid code at all. Here I'm meditating on chapter 3.1.1 in
[SICP], where rudimentary objects are introduced that have both methods
(instructions what to do) and [static variables], whose value is
retained between calls, on the example of bank accounts. SICP uses the
[LISP] dialect ''[Scheme]'' for its examples, and I very often wonder
whether we can do that in Tcl too.

Method dispatching based on an (typically the first) argument is well-
known in Tcl, as known from Tk, or
''[info] globals, [string] length, [file] delete...'', and also a
frequent style in [OO]. For static variables, which
for procedures can be implemented as default arguments, I
like ''remember'' best which first appeared in [Streams]:
 proc remember {argn value} {
    # - rewrite a proc's default arg with given value
    set procn [lindex [info level -1] 0] ;# caller's name
    set argl {}
    foreach arg [info args $procn] {
        if [info default $procn $arg default] {
            if {$arg==$argn} {set default $value}
            lappend argl [list $arg $default]
        } else {
            lappend argl $arg
        }
    }
    proc $procn $argl [info body $procn]
    set value
 }
# That's all we need to get started:
 proc make-account {id balance} {
    proc $id [list cmd amount [list balance $balance]] {
        switch -- $cmd {
          deposit  {remember balance [expr {$balance + $amount}]}
          withdraw {
                   if {$balance < $amount} {
                     error "insufficient funds"
                   } else {
                     remember balance [expr {$balance - $amount}]
                   }
          }
          default {error "unknown request $cmd"}
        }
    }
    set id ;# just in case the caller wants to re-use it
 }
if 0 {As in SICP, we return the account ID; but in contrast, we also
require it as an input parameter (otherwise an unique account numbering
scheme, with a global or static variable, would have to have been
included too). But this is no big limitation, if you look at the example
use cases:
 % make-account W1 100
 W1
 % make-account W2 100
 W2
 % W1 withdraw 50
 50
 % W2 withdraw 70
 30
 % W2 withdraw 40
 insufficient funds
 % W2 deposit 40
 70
 % W1 withdraw 33
 17
As in SICP, the independence and persistence of the accounts' balances
is demonstrated. Better don't base a bank on this code, however, because
it can be too easily cheated by overriding the balance:
 % W1 withdraw 33 9999999
 9999966
Hence, although this code shows how bare-bone objects (no inheritance
and stuff, just methods and static variables) can be had by just writing
a proc that writes a proc (which rewrites itself when state changes ;-),
"private variables" that are protected from meddling from outside are
less Tcl's cup of tea than transparency, openness and power...

In the above implementation, each account has its own proc. Assume we
have many accounts, whose methods may be updated over time - then it's
more economic (in memory) and robust to have the code just in one place,
and redirect the account instances to it with an alias that also keeps
the static variable(s):
}
 proc make-account2 {id balance} {
    if [llength [info commands $id]] {
        error "can't override command $id"
    }
    setBalance $id $balance
 }
 proc setBalance {id balance} {
    interp alias {} $id {} _account $id $balance
    set balance
 }
 ##-- the generic account exists only once, namely here:
 proc _account {id balance cmd amount} {
        switch -- $cmd {
          deposit  {setBalance $id [expr {$balance+$amount}]}
          withdraw {
                   if {$balance < $amount} {
                     error "insufficient funds"
                   } else {
                     setBalance $id [expr {$balance - $amount}]
                   }
          }
          default  {error "unknown request $cmd"}
        }
 }
Now maintenance of account policy (e.g., allowing limited overdraw,
paying interest, or charging fees) can be done in one place, the "class
code" for accounts, while the static data (the balance) is kept only in
the alias definition - not very "private" either, and cheating is again
possible by changing an alias, or calling ''setBalance'' directly...
----
See also [Tiny OO with Jim] and [Jim closures] - oh I wish Tcl had closures...
----
[Category Object Orientation] | [Object orientation] | [Arts and crafts of Tcl-Tk programming]