AW: [Xotcl] destroy invoked by object move?

[Gustaf Neumann]

Scott Gargash schrieb:
>
> xotcl-bounces at alice.wu-wien.ac.at wrote on 03/21/2006 02:28:15 AM:
>
> > i do not like the &-suggestions for the xotcl-core, since it looks
> > like an operator, not like a name. The &-operator is not
> > about fully qualifying a name, but about providing a reference
> > in general.
>
> What's the difference (in tcl) between a name and an operator or a 
> name and a reference?
>
> I'm not being sarcastic, you're making a distinction I don't see. 
>

i don't think, that you are expecting an detailed anwser. for example, a 
prefix operator is a
syntactical construct you can put in front of some other syntactical 
construct to express
some intention. One can for example put a "-" in front of a number to 
express that
you want to use its negative value. Similary, one can put a "$" sign in 
front of every
variable name in tcl to access the value of the variable. I would expect 
from a
operator & to be as general, to work the same way, no matter whether the 
variable is
global, on a stack frame, or in an object.

> The problem here is needing an external reference to an XOTcl member. 
>  In Tcl, that means you need the name of the variable. 
>
unfortunately this is currently not true in general. To reference e.g. a 
variable on
some stack frame, you will need upvar or similar constructs.
maybe someone writes a name resolver to achieve this, or implements a 
command
to achieve this a some time. Maybe then someone decides to use & for 
such purposes.
>
>
> > i get the impression that adding these cmds/methods do not reduce
> > significantly the clarity. myvar/myvarname makes sense for the
> > snitters.
>
> While that may be true for an experienced user, as a new user trying 
> to use XOTcl I find the way XOTcl uses namespaces (created on demand) 
> to be pretty confusing.  Anything that keeps me from needing to 
> understand that is a good thing.  And leaving aside the new user 
> issue, having a documented access mechanism for clients instead of 
> knowledge of the implementation seems like a good thing.
>
Maybe i made the mistake to explain some details (that a normal user 
does not need to know)
in order to dicuss the ease and feasability of some proposed constructs.
xotcl tries to hide tcl-namespaces to a good deal, but sometimes they 
look through.
as explained earlier, tcl-namespaces are simplifying xotcl in some respects,
in other respects they are a burden.

i certainly agree that providing a standard way of accessing instvars 
helps, therefore i think
we should add a command or method to xotcl to do so.

snit  uses snit::myvar and snit::varname (just a second name for the 
same command)
and snit::mymethod (the latter one as an alternative to [list somemagic 
somemethod someargs]).
itcl uses itcl::code for the latter.

So, in order to stick to these names, using ::xotcl::myvar and 
::xotcl::mymethod and
exporting these seems as a good idea. Exporting can turn out to be a 
problem when
someone uses snit and xotcl at the same time and needs to namespace 
import both for
some reason. I am somewhat unhappy that these commands suggest some 
non-existing
symmetry (myvar refers to an object-variable, while mymethod constructs 
a command
from a method name, and the method name is not restricted to be defined
within a command (or tcl-namespace)).

When using methodnames for the discussed functionality, we should invent 
new
names, since [my myvar ... ] and [my mymethod ...] look somewhat strange.
for ::xotcl::myvar, i think [my varname ...] is fine. for mymethod the 
naming
is harder. What is an improvement over "[list [self] method args]"?
"my code foo args",
"my cmd foo args",
"my invokecmd foo args",
"my callbackcmd foo args",
"my make_command_from_method_name foo args"

haveing listed these options, "::xotcl::mycmd" looks reasonale
to me, since it constructs a tcl command and avoids the "[self]"
in a similar way as "::xotcl::my".

More ideas, suggestions, comments?
best regards
-gustaf neumann