Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 16 May 2008 18:06:44 +0200

Dear Matthew,

the question is more of an OpenACS question than an XOTcl question.

however, some answers:
 - i was the "someone" who wrote a sample script for you.

> in the lines:
> ::xo::cc set_parameter master 0
> ::xo::cc set_parameter content-type $content_type
> what does the "::xo::cc" mean?

 - ::xo::cc is an the connection context object created by xotcl-core.
 - The connection context object contains per request information
 - The conneciton context ist used as well by the "view" method of
   XoWiki pages to control, whether or not the output should be
   included in a master adp file (with login etc or not). You will
   not like to have this around e.g. a json code.
  
> If the object is being created, how do I reference the object?

i have to assume, that by "object" you refer to an instance of the
class ::xowiki::Object. If you load the prototype page - as described
in my answer in the openacs forum - then an acs_object is
created in the openacs content repository. The entries in the
OpenACS content repository are referenced by name.
When you call e.g. http://..../xowiki/PAGEAME, an
::xowiki::Object with the name PAGENAME residing
in the content folder for the xowiki-instance will be fetched
from the content repository, on this object, the method view
is called, and the ouput is presented to the user.


> For instance, I would like to set a
> variable to "content". How would I do this?

 From your other positing in the OpenACS forum i see
that you want to include the page in some other adp page

you can do this
<include src="/packages/xowiki/lib/view" url="_at_url@"
template_file="view-links">

The variable "url" should point to the xowiki page to be included (e.g.
/xowiki/my_page).

best regards
-gustaf neumann

PS: it makes sense to concentrate the discussion to one place, e.g. the
OpenACS forums.

From: Kurt Stoll <kstoll_at_echelon.com>
Date: Wed, 13 Jun 2012 13:54:46 -0700

Gustaf and XOTcl list - thank you, and again apologies for polluting your mailing list with this traffic. ActiveState has identified the issue and provided me with a patch.

Thanks,
Kurt


> -----Original Message-----
> From: Kurt Stoll <kstoll_at_echelon.com>
> Subject: Re: [Xotcl] Loading XOTcl crashes
> Date: June 13, 2012 8:35:44 AM PDT
> To: Gustaf Neumann <neumann_at_wu.ac.at>
> Cc: xotcl_at_alice.wu-wien.ac.at
>
>
>
> Thank you Gustaf. I did open up a thread in their forum, but have not seen any responses yet. It's at:
>
> http://community.activestate.com/node/8750
>
> I'll see if I can find the error handling code that is being called to determine where the issue is.
>
> -Kurt
>
>
>> -----Original Message-----
>> From: Gustaf Neumann <neumann_at_wu.ac.at>
>> Subject: Re: [Xotcl] Loading XOTcl crashes
>> Date: June 13, 2012 12:16:34 AM PDT
>> To: xotcl_at_alice.wu-wien.ac.at
>>
>>
>> When everything works from the shell, and it works with Komodo V6 and it does not work with Komodo V7, then it certainly looks like a problem with Komodo V7. We do not have Komodo here, which is a commercial product (most likely with a commercial support). Is the a public visible forum with your discussions, maybe i can get a clue from it... From the snippet below, there seems to be a problem with the error handling (where i see nothing special from the xotcl side).
>>
>> -gustaf neumann
>>
>> On 13.06.12 02:33, Kurt Stoll wrote:
>>> (I realize that this is probably not an XOTcl issue, but a ActiveState Komodo issue; however, I have not been able to find an answer through ActiveState, so I may have better luck here.)
>>>
>>> Running on a Mac, using OSX V10.7.4.
>>>
>>> I cannot get XOTcl to load properly with ActiveState Komodo V7. I do not have any problem with V6 of that tool. Also, loading XOTcl into tclsh when invoked from the Terminal works. All three environments (Komodo V7, V6, and Terminal / tclsh) are using the same version of Tcl (8.5) and the same version of XOTcl (1.6.6 - I know, down rev by one release). All three versions point to the same library file: /System/Library/Tcl/8.5/xotcl1.6.6/libxotcl1.6.6.dylib.
>>>
>>> Yet, when I attempt to load XOTcl (using package require XOTcl) from Komodo V7, it gets stuck in an infinite loop:
>>>
>>>
>>> Error in predefined code
>>> too many nested evaluations (infinite loop?)
>>> while executing
>>> "DbgNub_infoCmd exists DbgNub(returnState)"
>>> (procedure "catch" line 11)
>>> invoked from within
>>> "catch {set savedErrorInfo $::errorInfo}"
>>> (procedure "::unknown" line 18)
>>> invoked from within
>>> ...
>>> "proc ::xotcl::myproc {args} {linsert $args 0 [::xotcl::self]}"
>>> too many nested evaluations (infinite loop?)
>>>
>>>
>>> I don't believe I have changed any relevant settings.
>>>
>>> Any clues?
>>>
>>> Thanks,
>>> Kurt Stoll
>>>
>>>
>>> _______________________________________________
>>> Xotcl mailing list
>>> Xotcl_at_alice.wu-wien.ac.at
>>> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>>
>> _______________________________________________
>> Xotcl mailing list
>> Xotcl_at_alice.wu-wien.ac.at
>> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: <MichaelL_at_frogware.com>
Date: Wed, 17 Sep 2003 10:08:58 -0400

No, that didn't work. I verified that a) my code with the qualified name
worked and b) if I removed the qualification it didn't work and c) if I
added your change it still didn't work.

With some effort I can strip down my code to just give you the essentials.
For what it's worth, here are the first few lines of the broken serialized
file:

        ::Collection create ::agenda::items -noinit -array set __autonames
{Item 11}
        ::Collection create ::agenda::categories -noinit -array set
__autonames {Category 2}
        ::mulAgenda::Agenda create ::agenda -noinit
        ::Collection create ::agenda::views -noinit -array set __autonames
{View 1}
        ...

You can see that lines 1 and 2 are creating objects that are aggregated
inside ::agenda--but ::agenda isn't created until line 3. If I fully
qualify the name I get what you'd expect:

        ::mulAgenda::Agenda create ::agenda -noinit
        ::Collection create ::agenda::items -noinit -array set __autonames
{Item 11}
        ::Collection create ::agenda::categories -noinit -array set
__autonames {Category 2}
        ::Collection create ::agenda::views -noinit -array set __autonames
{View 1}
        ...

However, Michael Schlenker's idea worked. I changed this:

        Serializer instproc deepSerialize o {
                my serializeList [my allChildren $o]
        }

to this:

        Serializer instproc deepSerialize o {
                my serializeList [my allChildren [namespace which $o]]
        }

Would such a change be required anywhere else?

Uwe Zdun <uwe.zdun_at_wu-wien.ac.at> wrote on 09/17/2003 04:44:00 AM:

> This is rather an unexpected behavior than a bug ...
> I think it would be ok, to force a full name for serialize and
> deepSerialize,
> that is, change the method in Serializer.xotcl to:
>
> Serializer instproc serialize {objectOrClass} {
> my [my category $objectOrClass]-serialize [$objectOrClass]
> }
>
> can you please check whether that would work in your example?
>
> --uwe
>

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Tue, 28 Sep 2004 18:49:48 +0200

Gustaf Neumann wrote:
> On Friday 17 September 2004 19:19, Catherine Letondal wrote:
>> Dear members of xotcl the list,
>>
>> Has someone any experience in installing XOtcl on MacOsX ?
>> I have found a "Portfile" but I don't know what to do with it?
>
> Catherine,
>
> isn't the Mac OS X Tcl/Tk Aqua 8.4.7 Release something for
> you to use, it contains XOTcl binaries.....
>
> http://groups.google.at/groups?q=xotcl&hl=de&lr=&ie=UTF
> -8&scoring=d&selm=pgpmoose.200408041618.26617%40despot.non.net&rnum=8

Thanks for the advice!

I have indeed installed the TclTkAquaBI and tried but it'svery
complicated.
I don't know whether you can help ?

1) I need to build my own wish with shared objects (libtcl.dylib
etc...) which
are not provided in TclTkAquaBI distribution - even using it together
with the native Tcl.framework
you don't have the *.h files etc...).
So I decided to use the Fink tcl/tk distribution which works fine.

2) Using the TclTkAquaBI (the one which includes xotcl-1.2) is also not
easy when you
want to link an xotcl shared object (called
/Library/Tcl/xotcl1.2/libxotcl1.2.dylib)
First, because you need xotcl.h, so you have to download separately the
sources
that have been used for building the shared library (sources are kindly
distributed
from http://tcltkaqua.sourceforge.net/8.4.7.html). Even using
libxotcl.dylib file distributed in TclAquaBI not not make sense for a
simple reason: if I need another package (such as BLT), which is not
distributed in TclAquaBI, I will also
have to compile it myself, which is very difficult when it is not
configured for this purpose (blt is also distributed in Fink).

3) So, sy conclusion was to compile Xotcl myself, which I did, I think,
successfully.
  configure;
./configure --with-tcl=/sw/lib --with-tclinclude=/sw/include
--with-tk=/sw/lib --with-tkinclude=/sw/include

  I just got errors when building xowish:

  gcc -pipe -rdynamic -o xowish tkAppInit.o \
         xotcl.o xotclError.o xotclMetaData.o xotclObjectData.o
xotclProfile.o xotclTrace.o xotclUtil.o xotclShadow.o xotclCompile.o
aolstub.o xotclStubInit.o \
         -O3 -Wall -Wconversion -Wno-implicit-int -fno-common -L/sw/lib
-ltcl8.4 \

gcc: unrecognized option `-rdynamic'
ld: Undefined symbols:
_Tk_Init
_Tk_MainEx
_Tk_SafeInit

Apparently also:
   ==> -ltk8.4 is missing ?

But xotclsh was successfully built.


4) then, I built a very simple tkAppinit.c:

#include "tk.h"
#include <xotcl.h>
int
main(argc, argv)
     int argc; /* Number of command-line arguments. */
     char **argv; /* Values of command-line arguments. */
{
     Tk_Main(argc, argv, Tcl_AppInit);
     return 0; /* Needed only to prevent compiler
warning. */
}

int
Tcl_AppInit(interp)
     Tcl_Interp *interp; /* Interpreter for application. */
{
     if (Tcl_Init(interp) == TCL_ERROR) {
         return TCL_ERROR;
     }
     if (Tk_Init(interp) == TCL_ERROR) {
         return TCL_ERROR;
     }
     Tcl_StaticPackage(interp, "Tk", Tk_Init, Tk_SafeInit);
     if (Xotcl_Init(interp) == TCL_ERROR) {
       return TCL_ERROR;
     }

     Tcl_Import(interp, Tcl_GetGlobalNamespace(interp), "xotcl::*", 1);
     if (Tcl_PkgRequire(interp, "XOTcl", XOTCLVERSION, 1) == NULL) {
       return TCL_ERROR;
     }

     return TCL_OK;
}

I got an executable (miniwish) built with the following compile/link
commands (with some warnings):

gcc -fno-common -DXOTCLVERSION=\"1.3.1\" -c -I/sw/include
-I/sw/include -I/usr/include/X11 -I/sw/include tkAppInit.c
gcc -bind_at_load -o minibiokwish tkAppInit.o -L/sw/lib -ltk8.4
-L/sw/lib -ltcl8.4 -L/usr/X11R6/lib -lX11 -lXmu -L/sw/lib/xotcl1.3.1
-lxotcl1.3.1 -lm
ld: warning multiple definitions of symbol _tclPlatStubsPtr
/sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclPlatStubsPtr
/sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclPlatStubsPtr
ld: warning multiple definitions of symbol _tclIntStubsPtr
/sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclIntStubsPtr
/sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclIntStubsPtr
ld: warning multiple definitions of symbol _Tcl_InitStubs
/sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _Tcl_InitStubs
/sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _Tcl_InitStubs
ld: warning multiple definitions of symbol _tclIntPlatStubsPtr
/sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr
/sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr
ld: warning multiple definitions of symbol _tclStubsPtr
/sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclStubsPtr
/sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclStubsPtr
/sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of
_tclPlatStubsPtr
/sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of
_tclIntStubsPtr
/sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of
_tclStubsPtr
/sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of
_tclIntPlatStubsPtr
/sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of
_Tcl_InitStubs

But this executable does not work correctly:

./minibiokwish
dyld: ./minibiokwish can't open library: libxotcl1.3.1.dylib (No such
file or directory, errno = 2)
Trace/BPT trap

(executed from an X11 environment - not Aqua - of course).

--
Catherine Letondal -- Pasteur Institute Computing Center

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Sat, 23 Feb 2002 18:47:27 +0100

On Friday 22 February 2002 21:37, you wrote:

> ...below is a still simpler version...
>

[cut]

Ehm, I'd say we'd have to take some more care about
encapsulation....

Consider procedure A calling procedure B calling procedure C.
Each of them try to create a "private" object "bar" from
the "foo" class. What happens?

The object from A gets overwritten from the B and then B gets
overwritten from C. That's not good.
We have to assure that all created object names are unique,
since they are visible from all calling frames.

I've posted the better solution to the mailing list
but it somehow never reached the list, so I'll try
it again. Below you'll find my last working version.
It uses a Tcl array to store variable-objectname bindings
so we know which object to destroy when a named variable
gets unset. This is needed since variable traces are
invoked AFTER the variable has already been deleted.
Furthermore, traces are invoked in the calling procedure
frame if we have a variable deletion because the procedure
is about to exit. This is tricky stuff, but I think i have
it under control now. See for yourself...
Oh yes, the Tcl array with bindings is kept in the callers frame.

> we we can make a bind command, where we
> can bind an object to a variable in the sense
> that
>
> a) the object is deleted, when the variable is
> unset
> b) the object can provide a print-value, when
> someone read the value of the variable
>
> this might be useful for e.g. associations as well,
> where you have an instance variable refering to
> an object, and once you delete the object (with its
> variables) you want to destroy the referred object
> (or decrement a reference counter)
>

Indeed; "bind" is a very good name for this.
We can also serialize the object when somebody does
the read on the bound variable. This way one can
pass objects per-value across function calls and
also over remote procedure calls.
Speaking of rpc, I have developed Tcl-like rcp
using the XOTcl, AOLserver and http as transport
so I can test the idea...

> PS: i have a little bad feeling about filters/mixins
> and uplevel/upvar and friends.
>

Huh, let me think deeply about that...


Now the code...
I changed "private" to "volatile" to emphasise the fact.


#------- CUT HERE -------

#
# Gets invoked from variable unset callbacks.
#
Class proc __gc {n1 n2 op} {
  set l [::expr {[::info level] > 0}]
  if {![::uplevel $l ::info exists __gc($n1)]} {
      ::incr l
  }
  ::uplevel $l \$__gc($n1) destroy
}

#
# Used to instantiate "volatile" objects.
# These get auto-destroyed when the procedure goes out of context.
#
Class instproc volatile {n args} {
  ::upvar $n v
  ::trace variable v u [list Class __gc]
  ::set v [[self] autoname -instance [self]]
  ::uplevel [::expr {[::info level]<2?1:2}] ::set __gc($n) $v
  ::eval [self] create $v $args
}

#
# Test routines
#
proc aa {} {
  _foo_ volatile obj
  $obj test
  bb
}
proc bb {} {
  _foo_ volatile obj
  $obj test
  cc
}
proc cc {} {
  _foo_ volatile obj
  $obj test
  unset obj
  dd
}
proc dd {} {
  _foo_ volatile obj
  $obj test
}
proc gctest {} {
  Class _foo_
  _foo_ instproc test {} {puts stderr "proc [info level -1] object [self]"}
  set cmds [info comm _foo_*]
  aa
  if {[info comm _foo_*] == $cmds} {
     puts stderr ok
  } else {
     puts stderr fail
  }
}

#------- CUT HERE -------

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 6 Feb 2001 15:23:39 +0200 (EET)

On Tue, 6 Feb 2001, Gustaf Neumann wrote:

> understanding of e.g. the composite model (like tk). I have
> implemented most of my GUIs via Motif, which is some respects easier
> to integrate, since it follows the idea "every widget has an ID"
> rather than "every widget is a command" (like in tk). The latter
> leads to the "conflict" with XOTcl, which says "every Object is a
> command". OTOH, solving this conflict is quite an interesting and
> generic challenge.

Well would it be possible with the method I suggested using filters
and a TkClass metaclass? This only required that you have basically
a header file which makes the equivalent TkClass instances. The filter
can operate so that it creates the Tk commands in a separate namespace
so as not to conflict. It then just passes the XOTcl methods directly
to the Tk command. Some specific XOTcl methods could be added too
like "pack" or "update".

I believe this would be quite a neat solution. It requires very little
work then to wrap a Tk "class" into a new XOTcl class, and the objects
feel like real XOTcl objects in every sense. Even better: this same
solution can be used for ITcl and other object-like things that need
to be wrapped in XOTcl.

         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

From: Kristoffer Lawson <setok_at_scred.com>
Date: Thu, 5 Aug 2010 15:47:33 +0300

The reference manual for [create] specifies that it calls alloc, searchDefaults, configure and then init. However I find no mention of searchDefaults elsewhere in the manual, and it does not appear to be available, at least for 1.6.

As I am experimenting with a replacement for [new] I would like to be able to pre-set the default values for parameters, upon class instantiation. Is this an oversight or am I looking in the wrong place?

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

From: Shishir Ramam <sramam_at_gmail.com>
Date: Wed, 7 Nov 2007 07:37:04 -0800

Thanks Gustaf and Artur!

Not sure if this should be considered expected behaviour - but does the type
have to be defined before declaration?
This simple script illustrates the issue - see the last couple of attempts.

Class Base -slots { Attribute connects_to -multivalued true -type Base }
Class DerivedA -superclass Base -slots { Attribute connects_to -multivalued
true -type DerivedB }
Class DerivedB -superclass Base -slots { Attribute connects_to -multivalued
true -type DerivedA }

Base b
DerivedA da
DerivedB db

b connects_to add da
b connects_to add db

db connects_to add b
>>> can't set "connects_to": b is not of type DerivedA << This should be
expected. all A-ok.

db connects_to add da
da connects_to add b
>>> can't set "connects_to": bad class "DerivedB": must be alnum, alpha,
ascii, control, boolean, digit, double, false, grap
h, integer, lower, print, punct, space, true, upper, wordchar, or xdigit

da connects_to add db
>>> can't set "connects_to": bad class "DerivedB": must be alnum, alpha,
ascii, control, boolean, digit, double, false, grap
h, integer, lower, print, punct, space, true, upper, wordchar, or xdigit


On Nov 7, 2007 12:06 AM, Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote:

> Shishir Ramam schrieb:
> > Hi,
> > I have a need to represent a directed graph in XoTcl.
> Here are two small examples for representing graphs
>
> In version one, edges are lists of references to nodes stored
> as attributes of nodes. By specifying "-multivalued true", it
> is possible to "add" or "delete" elements from the list.
> By using "-type Node" the code ensures, that only instances
> of Node may be added to the list, otherwise an error is thrown.
>
> Class Node -slots {
> Attribute connects_to -multivalued true -type Node
> }
>
> Node n1
> Node n2
> Node n3
>
> n1 connects_to add n2
> n1 connects_to add n3
>
> puts [n1 connects_to]
>
> A "destroy" of a nodes automatically destroys the
> edges as well, by refining the destroy method, one
> could as well destroy the referenced edges (similar
> to aggregation (nesting objects), but one has to be
> care about cyclical edges.
>
> Another approach is to define Edges as objects
> which makes it possible to provide methods for
> Edges and to store attributes in it.
>
> Class Edge -slots {
> Attribute from -type Node
> Attribute to -type Node
> }
>
> Edge e1 -from n1 -to n2
> Edge e2 -from n1 -to n3
>
> Simarly as above, when a dynamic graph
> is to be maintained, the destroy method of Node
> should care about deleting references in Edges
> to ensure referencial integrity.
> The easiest way is to check in the destroy method
> of Node all Edges with [Edge info instances], if
> their "form" or "to" attributes contain the node.
> One could as well build an index to make this
> operation faster for large graph via a constructor
> of Edge, which maintains e.g. a list of referenced
> edges per node (e.g. via multivalued attribute
> "references", similar to approach 1)
>
>
> -gustaf neumann
>
>

-- 
Don't worry about people stealing an idea. If it's original, you will have
to ram it down their throats.
 - Howard Aiken

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 07 Aug 2011 04:11:51 +0200

fixed in git -gustaf

On 06.08.11 22:11, Victor Mayevski wrote:
> Compiling NX against latest fossil Tcl source, on 32bit Ubuntu based
> distro, 2.6.35-30 kernel, after ./configure:
>
> # make
> Appending pkgIndex-package.add to pkgIndex.tcl in
> /root/NX/library/xotcl/library/lib
> Appending pkgIndex-subdir.add to pkgIndex.tcl in
> /root/NX/library/xotcl/library/store
> ... xotcl::metadataAnalyzer 0.85 loaded from
> './library/xotcl/library/lib/metadataAnalyzer.xotcl'
> ... xotcl::staticMetadataAnalyzer 0.84 loaded from
> './library/xotcl/library/lib/staticMetadata.xotcl'
> ... xotcl::htmllib 0.1 loaded from './library/xotcl/library/lib/htmllib.xotcl'
> ... xotcl::xodoc 0.84 loaded from './library/xotcl/library/lib/xodoc.xotcl'
> XOTcl Documentation Tool
> ------------------------
> Documenting to directory ./library/xotcl/doc:
> ..../library/serialize/serializer.tcl
> /bin/bash: line 3: 4401 Segmentation fault TCL_LIBRARY=`echo
> /root/tcl-src-fossil/library` LD_LIBRARY_PATH=".:/usr/local/lib:"
> PATH=".:/usr/local/lib:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
> TCLLIBPATH=". ." /usr/local/bin/tclsh8.6
> ./library/xotcl/library/lib/makeDoc.xotcl ./library/xotcl/doc $docs
> make: *** [library/xotcl/doc/langRef-xotcl.html] Error 139

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 15 Jul 2006 17:08:17 +0300

On 15 Jul 2006, at 17:00, Gustaf Neumann wrote:

> Kristoffer,
>
> the following might help you...
> -gustaf
>
>
> # a little helper
> Object instproc apply {list args} {foreach o $list {eval $o $args}}
>
> # turn off checking for all objects
> Object apply [::xotcl::Object allinstances] check ""

Except that this only works 'afterwards'. So it doesn't actually
help, as I'd still have to apply it after I create objects etc. when
really I just want to turn it on at the top of the application and
leave it at that.

For the moment I managed this with a filter that is called every time
an object is initialised, but I would imagine this the kind of thing
that should be handled elegantly by the XOTcl core?

            / http://www.fishpool.com/~setok/