On Fri, 24 Jan 2003, Gustaf Neumann wrote:
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.
[tie] needs it too, yes. The point is that is just one command which will handle all cases like that, instead of each case having to deal with it separately.
============================================ 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 ....
[tie] doesn't cover everything and is not the best for everything. For the specific case I demonstrated it is useful. In your [read] method, I would probably prefer to do this:
Client instproc read {} { my instvar reader tie msg [$reader getMessage] }
And thus the reader would not have to care what happens to the object after it returns it. I think [tie] sort of works neatly in that way as it's not realy to do with object creation but more of a statement "destroy the ob when the variable changes", whereas volatile feels more like something related to creation.
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] }
Perhaps your system is best for that, I don't know... -refcount can help in many situations but even then I feel that in [getMessage] I shouldn't care how destruction is handled.
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.
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...
Yeah. Great to be back on the mailing list participating :-) I have some strong sentimentality for XOTcl: I feel it's my kind of OO extension and I have great interest in seeing it succeed.