On Fri, May 25, 2012 at 1:38 PM, Jens Rehsack via RT <
bug-Hash-MoreUtils@rt.cpan.org> wrote:
Show quoted text> For the moment I tried to understand your reported problem(s) and fully
> agree that it is a bug which needs to fixed. The documentation is right
> there - that shouldn't happen. You're follow up confuses me a bit.
> Invoking slice with an empty list should return nothing. But any obscure
> extra parameters are nothing what would solve anything.
>
The point I was making in my followup is that for slice_def, slice_exists,
and slice_grep, an argument could be made that a usage like this would be
desirable:
my %hash = slice_def $hashref;
rather than doing it explicitly:
my %hash = slice_def $hashref, keys %$hashref;
I'm guessing this is the reason why the LIST parameter was made optional.
However, that breaks cases like:
my %hash = slice_def $hashref, @possibly_empty_list;
But you could get the convenience by putting a special parameter _before_
the hashref, e.g.:
use Hash::MoreUtils qw($ALLKEYS slice_def);
my %hash = slice_def $ALLKEYS $hashref;
Or you could pass something to the import to set the behavior (globally,
not so safe):
use Hash::MoreUtils qw(:use_allkeys slice_def);
my %hash = slice_def $hashref;
Or you could have a package variable dictating the behavior (importable or
not, no big deal):
local $Hash::MoreUtils::ALLKEYS = 1;
my %hash = slice_def $hashref;
Got the idea? I think of those three, the last is the most appealing, as
it allows global and local control so would provide an easy fix for
backward compatibility, and fine-tuned control for whichever behavior is
desirable. But you could always beg off and force people to do it
explicitly across the board. It's just a pain for people who are already
making use of that "feature".
--
Titi Ala'ilima
Principal Software Engineer
LeadKarma LLC
(617) 300 0202 x110
RT for rt.cpan.org