Comments wanted on these checkbutton techniques

[John Seal]

Suppose you have a checkbutton menu item whose job is to show or hide
some GUI element. A straighforward approach would be something like:

# Approach 1 - use helper procedure.
$m add checkbutton -label "Show foo" -variable foo \
-command {showHide .foo $foo}

proc showHide {widget showing} {
if {$showing} {
grid configure $widget
} else {
grid remove $widget
}
}

Where the helper is written generically enough to be shared with other
show/hide controls. (I personally don't like a lot of single-purpose
helpers, but best practice dictates that you use one for anything more
than a one-liner.) Now follow me on a process that I liken to squeezing
the code in one place, only to have it pop out in another place.

First, can we squeeze the helper completely out of existence? Sure;
notice that we're executing the same command, just with two different
subcommands:

# Approach 2 - no helper.
$m add checkbutton -label "Show foo" -variable foo \
-command {grid [expr {$foo?"configure":"remove"}] .foo}

IMO that is horrible... clunky and inelegant. Instead of computing the
state at widget invocation time, let's compute it at creation time:

# Approach 3 - use on and off values.
$m add checkbutton -label "Show foo" -variable foo \
-onvalue configure -offvalue remove
-command {grid $foo .foo}

I think that's nice. Can we squeeze the -command even more? Sure:

# Approach 4 - scripts in on and off values.
$m add checkbutton -label "Show foo" -variable foo \
-onvalue {grid configure .foo} -offvalue {grid remove .foo}
-command {eval $foo}

That has a certain fascination, but I wonder if to goes "too far". What
do you think?

[Ralf Fassel]

* John Seal <se...@indy.raytheon.com>

| # Approach 3 - use on and off values.
| $m add checkbutton -label "Show foo" -variable foo \
| -onvalue configure -offvalue remove
| -command {grid $foo .foo}
|
| I think that's nice. Can we squeeze the -command even more? Sure:

If the sole purpose is to grid/ungrid the GUI element, I like this one
best. If there is more to do than grid/ungrid, I'd use a helper proc
anyway, probably with passing the grid-action as parameter (not 1/0 as
in Approach 1).

| # Approach 4 - scripts in on and off values.

--<snip-snip>--

| That has a certain fascination, but I wonder if to goes "too
| far". What do you think?

I'd stay away from eval unless there is no other way
(just my EUR 0.02).

R'

[Bryan Oakley]

John Seal wrote:
> # Approach 4 - scripts in on and off values.
> $m add checkbutton -label "Show foo" -variable foo \
> -onvalue {grid configure .foo} -offvalue {grid remove .foo}
> -command {eval $foo}
>
> That has a certain fascination, but I wonder if to goes "too far". What
> do you think?

I think it goes too far. If I were reading the code for the first time
(without the aid of your explanation) I would stop dead in my tracks and
have to think about what you are doing. In other words, the code isn't
"obvious", and non-obvious code in my experience is harder-to-maintain code.

I personally think using a special-purpose helper proc is the better
solution. I see no advantage to trying to squeeze in a clever block of
code when something less clever and more straight-forward works just as
well.

Why do you have a problem with helper procs? Procs exist for our
convenience; there are no bonus points for using fewer procs (that I'm
aware of...).

--
Bryan Oakley
www.tclscripting.com

[John Seal]

Bryan Oakley wrote:
> Why do you have a problem with helper procs?

I don't, really. I use them all the time. But any time I can get
"everything in one place", I like to do it. I'm always on the lookout
for new idioms. Just yesterday I tumbled to [subst [regsub ...]]. Wow!

[Bryan Oakley]

John Seal wrote:
> ...Just yesterday I tumbled to [subst [regsub ...]]. Wow!

I can't imagine ever needing or wanting to do that. :-|

(but then, I use subst about once every two to three years so I'm a bit
biased against subst)

--
Bryan Oakley
www.tclscripting.com