Version 15 of OO

Updated 2007-03-03 12:05:55 by lwv

An acronym for object-oriented. (or was that "object-obsessed ?-) RS

Tcl abounds in extensions providing an object orientation (OO) programming style - see that previous link to read about incr Tcl and the many other extensions available for the tcl programmer. See Category Object Orientation for additional relevant hits.


Further, there are activities such as object-oriented analysis (OOA) and object-oriented design (OOD) that concern themselves with analyzing a system (or a solution to a problem) in terms of objects and their behaviors.


"An object or two may sometimes be nice, just like a glass of beer. But one shouldn't start drinking at breakfast." (RS)


RS In a smokebreak, I whipped up this hierarchy of things, by weight:

  • 1. process
  • 2. thread
  • 3. interp
  • 4. namespace
  • 5. commands, persistent vars
  • 6. local vars
  • 7. values (TclObjs) - strings, lists, dicts, ...

Every "heavier" thing can contain zero or more of "lighter" things. And on each level one can implement "objects". Most use 4., TOOT uses 7. procs with -static variables could allow (some) OO in 5. Databases are (fat) objects at level 1.


Another shade of meaning for OO is

 What: OO
 Where: http://www.cs.umn.edu/%7Edejong/tcl/OO.zip 
 Description: OO extension that works in Tcl 7, Tcl 8, and Jacl.
 Updated: 08/1998
 Contact: mailto:dejong at cs.umn.edu 

As RS aptly observes in "interp alias", object methods can be described as syntactic sugar for a certain form of dispatching. - RS 2005-03-27: I'd even go further and say that quite a bunch of what is called OO can be done in pure Tcl without a "framework", only that the code might look clumsy and distracting. Just choose how to implement instance variables:

  • in global variables or namespaces
  • or in closures, e.g. with Jim
  • or just as parts of a transparent value, with TOOT

The task of frameworks, be they written in Tcl or C, is just to hide away gorey details of the implementation - in other words, sugar it :) As an example, here's a Stack class with push and pop methods:

 namespace eval Stack {set n 0}
 proc Stack::Stack {} { #-- construktor
   variable n
   set instance [namespace current]::[incr n]
   namespace eval $instance {variable s {}}
   interp alias {} $instance {} ::Stack::do $instance ;# $object method arg.. sugar
 }
 proc Stack::do {self method args} { #-- Dispatcher with methods
   upvar #0 ${self}::s s
   switch -- $method {
       push {eval lappend s $args}
       pop  {
           if ![llength $s] {error "stack underflow"}
           K [lindex $s end] [set s [lrange $s 0 end-1]]
       }
       default {error "unknown method $method"}
   }
 }
 proc K {a b} {set a}

Other examples for this framework-less "bare-bone OO" are at Skeleton OO, A little IO stack, Tiny OO with Jim, and Jim closures. A framework would just have to make sure that the above code is functionally equivalent to, e.g. (in a fantasy OO style):

 class Stack {
    variable s {}
    method push args {eval lappend s $args}
    method pop {} {
           if ![llength $s] {error "stack underflow"}
           K [lindex $s end] [set s [lrange $s 0 end-1]]
    }
 }

which, I admit, reads definitely better. But bare-bones has its advantages too: in order to see how a clockwork works, you'd better have all parts visible :)


Category Acronym