No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Changing a parameter's -setter function
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 17 Mar 2006 17:05:19 +0100
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
Date: Fri, 17 Mar 2006 17:05:19 +0100
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