Re: Hm. ItemFactory vs. gtk2-perl 0.90 ? :)



Ross McFarland wrote:

... proposed change to the behavior of Gtk2::ItemFactory->create_item
 under the hash input type:

[ code snipped ]

reason i post this is two fold. 1) desire for a consensus on whether
or not this is the best manner/behavior. 2) for you perl magicians
out there to suggest a better way of doing this. ...

Ok, I'm a sucker for this kind of thing.  So what.

I heartily agree with complaining about keys that aren't recognized.
That's the kind of typo error that I really appreciate hearing about
sooner rather than later.  And you only pay once, when the menu is
constructed.

I'm not quite sure why you want to take the nice hashed data and move it
into variables, but here's a slightly more compact version:

my %valid_keys = (
   'path'            => \$path,
   'accelerator'     => \$accelerator,
   'callback'        => \$callback,
   'callback_action' => \$callback_action,
   'item_type'       => \$item_type,
   'type'            => \$item_type,   # aka, just for fun
   'extra_data'      => \$extra_data,
);

foreach my $key (keys %$entry) {
    if (exists $valid_keys{$key}) {
        ${$valid_keys{$key}} = $entry->{$key};
    }
    else {
        carp("Gtk Item Factory Entry; unknown key ($key) "
             . "ignored, legal keys are: ",
             join(', ', keys %valid_keys));
    }
}

I prefer to concentrate valid data in one place, so I don't have to
worry about different parts of my code getting out of sync.

One problem common to both versions: the variables that get set by one
hash will still be around when the next entry gets run through the loop.
 They have to be unset in between somehow, or the contents will carry over.

<Joe






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]