[Xotcl] "tie" command

[Gustaf Neumann]

On Friday 24 January 2003 17:48, Kristoffer Lawson wrote:
> On Fri, 24 Jan 2003, Gustaf Neumann wrote:
> >  The caller can certainly do with the object whatever she wants.
> >  if these are properties needed in the creation method they
> >  have to be passed somehow there, or the object can be altered,
> >  or one can put a mechanism on top of the creation to handle this.
> >  I personally would not have a problem in using two different method
> >  names for the different cases, like
> >    set msg [$cmdReader getMessage]
> >    set msg [$cmdReader getNewMessage]
> >  or to use an option like in
> >    set msg [$cmdReader getMessage -volatile]
>
> But that doesn't solve the issue. $cmdReader cannot create the object
> itself as volatile or bound to a variable as it will then be destroyed the
> minute getNewMessage returns! Or, of course it could always use uplevel
> and upvar but then every method that wants to return an object that may or
> may not be bound to a variable has to provide this extra functionality and
> argument checking. Ie. the methods need to be concerned with what the
> caller wants, and I don't believe this is necessary a good thing.

 well, completely without uplevel/upvar or the like it is hard to find 
 a solution. also tie needs it. passing the options via args is not painful.
 "uplevel" is only used for -volatile, which is scope-dependent.

============================================
Class Msg
 
Class CmdReader
CmdReader instproc getMessage args {
  uplevel [concat [list Msg new] $args]
}

Class Client -parameter reader
Client instproc read {} {
  my instvar reader
  set msg [$reader getMessage -volatile]
}

Client c1 -reader [CmdReader new]
============================================

The instvar "reader" is btw. a good example, where i prefer control
in the new command rather than in the calling environment. 
"tie" is here no good solution either. "new -refcount" would be
much nicer .... 
  
> Again, I'm not saying this feature is absolutely essential, but if one
> decides to add it I believe it should be done in the best possible way ;-)

these discussions are great. we have a young language/extension, where
we can try to find "the right" way (whatever this is) and we can implement
it with not to much hassle...

-gustaf

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien