in reply to Re: RFC: List::Extract
in thread RFC: List::Extract

Overall, I like the idea of "extract", and I don't know of any equivalent (it sounds vaguely like some sort of set operation, but there's nothing like it in Set::Scalar, for example). It would indeed be a good addition to List::MoreUtils, if the maintainers of it are amendable -- but I can understand why you might want to just go ahead and package it up on CPAN and skip the negotiation process. I like the name "extract", myself (an alternate name might be "move"). I think the naming implies that any modifications to $_ should be discarded (but maybe that's reasonable in an un-perl like way, eh?). I would suggest writing variant versions that preserve side-effects but use different names for them, possibly "map_extract" or something like that.

Replies are listed 'Best First'.
Re^3: RFC: List::Extract
by lodin (Hermit) on Nov 25, 2007 at 01:37 UTC

    Thanks for you feedback.

    About keeping or discarding changes. Currently I'm leaning towards keeping changes in the returned list, but discarding changes for the other elements.

    Here's an example that motivates keeping the changes for the returned list: 

    my @keywords = qw/ foo !bar baz /;
my @exclude = extract { s/^!// } @keywords;

    [download]
    If changes are discarded you'd have to do ugly workarounds to not duplicate the logic. But if the changes are kept and you don't want them it's trivial to change the behaviour: just add local $_ = $_;.

    The reason I want to discard changes for elements left in the array is that if changes is kept for the returned array then changes are kept for all elements, and then you can usually just as well do those changes to the array before extract.

    lodin

[reply]
[d/l]
[select]
      i agree, especially since grep has the same 'unimplied' aliasing of $_.
[reply]
[d/l]
[select]

        i agree, especially since grep has the same 'unimplied' aliasing of $_.

        Right, that's what I meant about discarding changes being reasonable, but possibly in an "unperl-like way"

        Remember that with grep changes made to $_ propagate in both directions, effecting the source as well as the returned values: "Note that $_ is an alias to the list value, so it can be used to modify the elements of the LIST."

        That side-effect of changing the source values was probably a bad idea and getting rid of it in "extract" would be all to the good.

        It is a good point that it's hard to see why you would want to discard a modified $_ in the returned values -- if so, then why did you modify it?

[reply]
Re^3: RFC: List::Extract
by doom (Deacon) on Nov 25, 2007 at 22:43 UTC
    By the way, I looked around on CPAN again for something like "extract". The closest I've found is List::Part, which takes a list and subdivides into two according to a given critereon. 
        my ($success, $failure) = part { /^ERR/ } <LOG>;

    [download]

    It follows the "grep" convention: modifications to $_ effect both the source and the results, as I verified with a test script: 

    use List::Part;
my @candidates = qw( !britney !paris bettie patti );
my ($hot, $not) = part { s{^!}{} } @candidates;
print "hot: ", Dumper( $hot ), "\n";
print "not: ", Dumper( $not ), "\n";
print "stuff: ", Dumper( \@candidates ), "\n";

    [download]
[reply]
[d/l]
[select]

In Section Meditations