develooper Front page | perl.perl5.porters | Postings from March 2021

Re: Let's talk about trim() so more

Thread Previous | Thread Next
Darren Duncan
March 27, 2021 03:34
Re: Let's talk about trim() so more
Message ID:
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;

   my $result2 = [];
   foreach $elem (@{$input2})
     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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About