Home > Archive > Tcl > June 2006 > XOTcl and namespace
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
XOTcl and namespace
|
|
| Manfred Stelzhammer 2006-06-25, 8:05 am |
| I have a small script
##script start
package require XOTcl
namespace import xotcl::*
Class Myclass
Myclass instproc init {} {
my requireNamespace
pack [entry .en -textvariable [self]::myvar]
pack [label .lab]
pack [button .bu -text start -command ".lab configure -text
$[self]::myvar "]
}
##case 1
Myclass myclass
##case 2
Myclass new
## script end
In case 1 the script run as expected.
In case 2 I get an error <<can't read "xotcl::__" no such variable>>
What's wrong, if the objectname is generated automatic.
Regards
Manfred
| |
| stephanearnold@yahoo.fr 2006-06-25, 7:06 pm |
|
Manfred Stelzhammer a =E9crit :
> I have a small script
> pack [button .bu -text start -command ".lab configure -text
> $[self]::myvar "]
> ##case 2
> Myclass new
> In case 2 I get an error <<can't read "xotcl::__" no such variable>>
The object name in this case is xotcl::__#1.
The hash symbol seems not to be allowed in a variable name.
Add this proc to your program and it will work :
Myclass proc new args {
eval my [my autoname myclass] $args
}
(taken from the XOTcl documentation, I just changed the class name)
Regards,
St=E9phane
| |
|
|
stephanearnold@yahoo.fr wrote:
> The object name in this case is xotcl::__#1.
> The hash symbol seems not to be allowed in a variable name.
interesting; i have not seen any limitations on the variable names in
tk in the documentation.
Is this considered a bug or a feature in tk?
| |
| Donal K. Fellows 2006-06-26, 4:21 am |
| GN wrote:
> interesting; i have not seen any limitations on the variable names in
> tk in the documentation.
There aren't any. It's not a Tk limitation. It's a limitation on the set
of characters supported by Tcl's $var substitution syntax, and it has
been there for at least a decade; I don't know when the $var syntax was
originally introduced, so I can't comment further without gnosticating
over the Tcl changes file. :-) That makes the problem something that is
actually in the user's script, and not in any library.
> Is this considered a bug or a feature in tk?
It's considered to be "the way it is". I suppose that makes it a
feature, except it isn't really something that we particularly feel
proud of. :-)
The work-around for this is to use single-arg [set] syntax, which has
*no* limitations on variable names (well, not quite[*]; none that matter
here is perhaps a fairer thing to say). Like this:
pack [button .bu -text start -command \
".lab configure -text \[set [self]::myvar]"]
The backslash is needed here because the expansion of the [set] would
otherwise happen at button creation time (unlike with the $ version).
Donal.
[* There are limitations on things that look like arrays and on colon
handling, but these are hardly ever problems in practice. ]
| |
| Michael A. Cleverly 2006-06-26, 7:07 pm |
| On Mon, 26 Jun 2006, GN wrote:
> stephanearnold@yahoo.fr wrote:
>
> interesting; i have not seen any limitations on the variable names in
> tk in the documentation.
> Is this considered a bug or a feature in tk?
See rule #7 from the endekalogue/tcl man page (the following from
http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm#M11), ${xotcl::__#1} should
work just fine:
[7] Variable substitution.
If a word contains a dollar-sign (``$'') then Tcl performs variable
substitution: the dollar-sign and the following characters are replaced in
the word by the value of a variable. Variable substitution may take any of
the following forms:
$name
Name is the name of a scalar variable; the name is a sequence of
one or more characters that are a letter, digit, underscore, or namespace
separators (two or more colons).
$name(index)
Name gives the name of an array variable and index gives the name
of an element within that array. Name must contain only letters, digits,
underscores, and namespace separators, and may be an empty string. Command
substitutions, variable substitutions, and backslash substitutions are
performed on the characters of index.
${name}
Name is the name of a scalar variable. It may contain any
characters whatsoever except for close braces.
There may be any number of variable substitutions in a single word.
Variable substitution is not performed on words enclosed in braces.
Michael
| |
|
| Michael A. Cleverly schrieb:
> There may be any number of variable substitutions in a single word.
> Variable substitution is not performed on words enclosed in braces.
>
> Michael
well, i know this, but how can one force tk to "put these braces around
the variable name", where ever it does the subst?
| |
| Michael A. Cleverly 2006-06-27, 10:00 pm |
| On Tue, 27 Jun 2006, GN wrote:
> Michael A. Cleverly schrieb:
>
> well, i know this, but how can one force tk to "put these braces around
> the variable name", where ever it does the subst?
You can't. But you could use [set var] instead of $var.
Michael
| |
|
|
Michael A. Cleverly schrieb:
> You can't. But you could use [set var] instead of $var.
>
> Michael
Thanks, got it. the problem was not the line with the textvariable (all
names are allowed) but the command of the button. The following command
does the trick with the curly braces:
pack [button .bu -text start -command ".lab configure -text
\${[self]::myvar}"]
| |
| Bryan Oakley 2006-06-27, 10:00 pm |
| GN wrote:
> Michael A. Cleverly schrieb:
>
>
>
> Thanks, got it. the problem was not the line with the textvariable (all
> names are allowed) but the command of the button. The following command
> does the trick with the curly braces:
>
> pack [button .bu -text start -command ".lab configure -text
> \${[self]::myvar}"]
>
Personally I'd never recommend creating a binding that depends on a
variable like that with quoting like that. Why? Because I had to read it
about 5 times before I really understood what you are trying to do (and
not having followed the thread and seen the context, I'm still not sure
why all the quoting is necessary).
Can't you write a proc or method inside of [self] that doesn't have to
fully qualify myvar? I'm sure this isn't the right xotcl syntax, but I
think the spirit of the code is correct:
button .bu -command [list config_lab .labe myvar]
proc [self]::config_lab {w} {
variable myvar
$w configure -text $myvar
}
Using pure namespaces, doesn't the following also do what you want
(assuming [self] is the same as the current namespace)?
button .bu -command [namespace code {
.lab configure -text $myvar
}
--
Bryan Oakley
http://www.tclscripting.com
| |
|
|
Bryan Oakley schrieb:
> Personally I'd never recommend creating a binding that depends on a
> variable like that with quoting like that. Why? Because I had to read it
> about 5 times before I really understood what you are trying to do (and
> not having followed the thread and seen the context, I'm still not sure
> why all the quoting is necessary).
it was not my code; i was trying to help out and misread one of the
former replies in a way, that tk performs somewhere in the entry widget
a subst and was  that i could not find a subst in the tk
source...
i fully agree that the construct is hard to read. This is due to the
fact that the namespace returned by self contains a character that is
not valid in ab unbraced dollar substitution.
the original command contains "... $[self]::myvar ...", which is indeed
tricky, since the $ is not evaluated during command registration, but
in the callback (the dollar substitution stops due to the bracket)
proc x {} {return "_#1"}
% set y $[x]::name
$_#1::name
when the callback is evaluated, the hash sign causes troubles. i would
rewrite the line as
pack [button .bu -text start -command [list [self] eval {.lab
configure -text $myvar}]]
or either as a separate method
Myclass instproc start_cmd {} {
my instvar myvar
.lab configure -text $myvar
}
pack [button .bu -text start -command [list [self] start_cmd]]
both approaches work with arbitrary namespaces without to much magic.
|
|
|
|
|