No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] "tie" command
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 24 Jan 2003 20:37:41 +0100
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
Date: Fri, 24 Jan 2003 20:37:41 +0100
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