From: Mo D. <md...@un...> - 2003-01-29 00:15:45
|
On Wed, 29 Jan 2003 00:17:27 +0100 Peter Spjuth <pet...@sp...> wrote: > It's an interesting idea, and perfectly doable, but I don't > like it for a couple of reasons. > > First, that is marks the ones that should not be expanded. > When I write a code line that needs argument expansion, it is the > thing to expand that is in my thoughts. Fair enough. > Second, it uses an established syntax, braces, for something that > does not mean the same thing. It sits rather deep in my mind that > braces mean "do not substitute", and suddenly it means "substitute > but do not expand". I see some confusion waiting to happen there. Well, you could also think of it as waiting to subst a {$var} until the second round. Since expand is kind of like eval, I don't think that is such a stretch (ok, it is not exactly the same). % proc p { arg1 arg2 } { puts "arg1 is $arg1, arg2 is $arg2" } % set two 2 2 % eval p $two {$two} arg1 is 2, arg2 is 2 Another question along these lines is how a user will construct a command with expanded arguments and run it later on. The expand command will do the expansion and call eval, but what if a user wanted to expand now and run the command later on? What about some sort of -noeval flag that will return the expanded elements in a properly formatted list instead of evaling it. Like so: set cmd [expand -noeval {cmd @[get_values]}] button .b -command $cmd cheers Mo |