[Xotcl] "tie" command
Gustaf Neumann
neumann@wu-wien.ac.at
Fri Jan 24 21:13:34 CET 2003
> I haven't really thought of volatile much, the
> following doesn't seem "right" somehow:
>
> Client instproc read {} {
> my instvar reader
> volatile msg [$reader getMessage]
> }
funny enough, i was rather thinking on something like:
===================
Object instproc objectref varname {
uplevel [list trace variable $varname wu [list [self] objectref_cb]]
}
Object instproc objectref_cb {n1 n2 mode} {
upvar $n1 name
my instvar [list __last($n1,$n2) old]
if {[info exists old]} {
if {[my isobject $old]} { $old destroy }
}
if {[info exists name] && [string equal $mode "w"]} {
set old $name
}
}
=====================
where one can use it like:
=====================
Client instproc read {} {
my instvar reader
my objectref msg
set msg [$reader getMessage]
}
====================
or combined to what the tie did before... this leads to some variable-declarations,
where we could also define parameters as references....
Class C -parameter {{a ""} {b -default "....."} {c -objectref} ...}
> What if you could specify after creation what happens to the object?
> Like:
>
> Client instproc read {} {
> my instvar reader
> set msg [$reader getMessage]
> $msg memmanagement refcount
> }
>
> I mean, in addition to the "-refcount" option with [new]. That way methods
> that should not know about the dynamics (like [getMessage]) can use normal
> [new] and let the caller decide what it wants to do with the object.
this is a good idea, except in cases, where the characteristics have
to be known at creation time. i will think about it....
-gustaf
--
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien
More information about the Xotcl
mailing list