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.
/
http://www.fishpool.com/~setok/
