Scott Gargash schrieb:
xotcl-bounces@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