Front page | perl.perl5.porters |
Postings from February 2022
On Sat, 26 Feb 2022, 16:50 Ovid via perl5-porters, <perl5-porters@perl.org>
wrote:
> Apologies if these bits are already decided. Feel free to ignore.
>
> On Friday, 25 February 2022, 19:20:50 CET, David Nicol <
> davidnicol@gmail.com> wrote:
>
> > Is it set in stone yet that trim takes only one arg (has a ($)
> prototype)?
> >
> > Compare:
> >
> > my @trimmed = trim @strings; # handling multiple arguments is
> orthogonal to in-place or not
>
> I don't think that's orthogonal. If we do in-place on the grounds that
> things like chomp() do that, I would ask why chomp() allows a list and
> trim() does not.
>
> Also, in-place means that this is going to bite people:
>
> my @orig = ...; # must not be changed
> my @new = map { trim } @orig; # oops. you changed it
>
> Even if in-place also returned the trimmed value, we've mutated our
> original list, so I need to make an extra copy to protect it. That's an
> annoying bit of structural code to need to remember to achieve the behavior
> I want. (though in practice, I don't know that this would be a big deal).
>
> Also, I've had a couple of weird "action at a distance" issues I've
> debugged in the past because someone's written something like `s/x/y/ for
> @_` and there's been a constant passed to the sub in question.
>
> Having trim() behave like, well, just about every other language would not
> only avoid what I think are traps (but maybe not serious ones), but also be
> less surprising (the more serious issue).
>
Just want to be clear that noone has suggested in place edit would work
like that. Some have suggest it should do in place in void context but
LeoNerd has spelled what I believe is generally agreed that context
dependent action like that is problematic. It would/should only do inplace
if the target and subject are the same. Eg
$foo=trim($foo);
Your map example is neither in void context nor is its target and subject
the same.
Cheers
Yves
>
>
Thread Previous
|
Thread Next