Re: [Xotcl] "tie" command

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 24 Jan 2003 22:13:34 +0100

> 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