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

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

Replies are listed 'Best First'.
Re^4: RFC: List::Extract
by mreece (Friar) on Nov 25, 2007 at 03:52 UTC
    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]

In Section Meditations