|
From: Jeff H. <je...@Ac...> - 2004-08-30 19:52:46
|
> set cmd [$w cget -command]
> - if {$cmd ne ""} {
> - uplevel #0 "$cmd scroll $n $units"
> - }
> + if {[llength $cmd]} {
> + uplevel #0 [concat $cmd scroll $n $units]
> + }
> This forces the -command option to be a list ([llength
> $cmd]), but still treats it as a string ([concat] instead of
> [linsert _ end ...])
I should have used [linsert $cmd end ...] to be better
behaved, but I figured the above was "safer".
> The new formulation may have a small performance boost in
> the common case where the -command is a pure list, but
> it's not fully backwards-compatible, since there are
> valid script prefixes that aren't lists.
No there aren't. You couldn't pass it to eval or uplevel
in that case:
(Tcl) 49 % set cmd "echo \{ c"
echo { c
(Tcl) 50 % llength $cmd
unmatched open brace in list
(Tcl) 51 % eval $cmd
missing close-brace
(Tcl) 52 % uplevel #0 $cmd
missing close-brace
> We had discussed earlier interpreting callback options
> that append arguments as command prefixes instead of script
> prefixes; is this something we want to do? (Callback options
> that don't append arguments would still be interpreted as
> scripts.) Personally, I think it's a good idea, but there
> are backwards-compatibility issues.
The real trick is "script prefix" vs "command prefix". I guess
for most of Tk it's a script prefix, and that remains that way
as long as we use uplevel. It really matters at the C level,
as there we can force it to be one command, vs a script. I'm
inclined to say "script" just because that's Tk-ish, but I'm
sure I could be convinced otherwise.
Jeff
|