XOTcl/NX mailing list by object move?

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 26 Mar 2006 13:25:14 +0200

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