Scott Gargash schrieb:
This works (I get the behavior I desire), but it means I have to 1) define a proc that duplicates the default behavior and 2) construct n identical copies of the implementation for the -setter proc, when really I can get by with the default behavior and one copy of the override behavior shared across all instances, just revectored the setter behavior once it's safe to do so.
there is as well the option to use a mixin or to use namespace import to share the proc.
# What I'd prefer Class create A -parameter {foo} A instproc init {args} { # [self] is valid, revector [self]'s foo setter from default to the side-effectful variant [self] parametercmd {foo -setter myfoo} } A instproc myfoo {p v} { my set $p $v # do side effects }
in general, it is certainly possible to parametercmd/instparametercmd; i am currently working on a general overhaul of parameter etc. based on a more general slot mechanism that generalizes parameters and object/class relations (class, superclass, mixins, ...) with more poweful ways to initialze data, etc. one can use e.g "... superclass add " in the same way than "mixin add", and in the same way as one can do this for ordinary attributes. While i am more interested in a powerful and extensible structure, i am also condidering extending the paramtercmd...
Besides being more memory efficient, it seems to more clearly express my intent. As you say, a trace would work, but traces tend to look and feel a bit like magic.
not so bad:
Class create A -parameter {foo} A instproc myfoo {var sub op} { puts "$var is now [my set $var]" } A instproc init {args} { my trace add variable foo write [list [self] myfoo] }
A a1 -foo 123 puts HU puts [a1 foo 234]
I've seen the part of the tutorial about wrapping C-extensions with XOTcl, but is there a reference/tutorial for extending XOTcl in C? How would I go about reimplementing a method in C? Can I just use the vanilla Tcl API or do I need to compile/link against XOTcl also?
there were some recent postings in this regard. in short: look for e.g. the gdbm integration part of the xotcl distribution, or into critcl.
One thing that has confused me so far is the "namespace on demand" concept. Where are instance variables stored if not in a namespace?
% Object a ::a % a set foo 123 123 % namespace exists a 0
Where does Object a's foo variable reside?
xotcl allocates namespaces on demand. this is a speed and memory issue. in earlier versions, every xotcl object had its own namespace, and was quite heavyweight (around 2001). The namespace allocation on demand lead to a significant improvement in speed and memory, since most objects do not need the namespaces. namespaces are allocated on demand, when an object defines procs or subobjects. When no namespace is allocated, the variables are stored in a private hash-table. You can force xotcl to allocate a namespace for an object by "Object create a -requireNamespace"
If I wanted to implement a method as a C function, how does the C function find the value of "[a set foo]" via the Tcl API? I.e., what would I pass as the varname to Tcl_GetVar()? Or do I need XOTcl's C API to look it up? Where do I install my C commands such that they are found automatically by XOTcl's method lookup alogrithm?
look at the XOTclSetterMethod() in xotcl.c, it is (currenty) quite simple.
hope this helps -gustaf neumann