Front page | perl.perl5.porters |
Postings from March 2021
On 2021-03-26 5:08 p.m., Ricardo Signes wrote:
> On Fri, Mar 26, 2021, at 6:40 PM, Darren Duncan wrote:
>> I know I wasn't following this issue in detail but I was always assuming that a
>> trim() would NOT modify its argument and would return the trimmed value. This
>> is what everyone would reasonably expect. This is the only version that is
>> actually useful..
>
> This is a weird position to take in the face of people (including me and several
> Perl programmers not on this list whom I asked) expecting modify-in-place and
> thinking it would be useful.
>
> I'm not even trying to tell you to agree. I'm just saying "no one would expect
> that or find it useful" is … well, a weird claim. (Do you think I would be
> suggesting we adopt some behavior that I found surprising and useless?)
I take back what I said about "no one would expect or find that useful".
Its more accurate to say that when I superficially followed and gave my support
for the idea that having trim() in core would be a great idea, I just assumed it
was a function one would include as part of a larger expression.
When Scott Baker started the current thread, it caught me completely by
surprise, that was the very first time I personally saw any mention of trim()
altering its argument, and it was the very first time I realized, oh, this could
be the design decision that was going in, and I didn't know until Scott pointed
it out.
In regards to what people would expect, I think it comes down to whether people
think more functionally or procedurally.
So which of these is considered better code?
Functional design:
my $result1 = op2(op1($input1));
my $result2 = [map { op2(op1($_)) } @{$input2}];
Procedural design:
my $result1 = $input1;
op1($result1);
op2($result1);
my $result2 = [];
foreach $elem (@{$input2})
{
op1($elem);
op2($elem);
push(@{$result2}, $elem);
}
It seems to me that those who prefer trim() to return the altered version would
more likely code functionally, while those who prefer trim() to modify its
argument would code more like the second example.
Now see value in having 2 versions of trim() to give each behavior, kind of like
how years ago Perl had the very welcome improvement with the /r switch to make
regular expressions return instead of modify.
But I'm saying making the arg-modifying version of trim() the only version is
making things harder for people that don't want to have extra temporary
variables or modify their inputs.
We finally got /r and any regex shorthands like trim() shouldn't take away that
benefit for the users of the shorthands.
-- Darren Duncan
Thread Previous
|
Thread Next