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

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

Thread Previous | Thread Next
B. Estrade
March 27, 2021 00:54
Re: Let's talk about trim() so more
Message ID:
Just replying to the latest, not necessarily this post. But I think it 
is reasonable to consider the precedent set by chomp(). In the GH 
thread, it seemed there was some confusion that trim was going to 
provide just the trim'ing of *leading* white space. I think this is a 
reasonable assumption that it was completing the corollary of chomp.

I think it is reasonable "trim" does "chomp + trim leading white space" 
which is a common idiom - perhaps vulgar, but an idiom nonetheless. The 
fact that trim returns the value rather than affecting the value itself 
- an idiom we're used to via passing data by reference - is *surprising*.

So we're dealing with two surprises with trim:

1. it trims leading *and* trailing white space
2. it *returns* the modified value rather than modifying it in-place, 
like chomp

Aside from the ideal of not polluting the keyword name space and going 
down that slippery slope, we should strong consider that principle of 
least astonishment for those familiar with Perl and chomp.

This leads me to be inclined to want a chomp that trims leading white 
space and behaves as chomp does with the value it is passed. Perhaps 
it's a misdesign that chomp behaves the way it does, but it can't be 
ignored that it behaves as it does.

All of this is coming for a "Perl purist" POV, which is probably not 
really even a thing. Ultimately, I can say, that "trim" as proposed 
behaves differently than chomp (what I am used to) and in fact is a 
superset of its functionality + handles the provided argument.

If there is to made a special for providing a super set of chomp while 
behaving differently, then it could open the floodgates. In my mind the 
options are:

a. leave chomp as a special case and leave "trim" functions in CPAN 
(where it might belong, as has been noted), or
b. provide a trim that is "chomp but for just the leading white space"

At the end of the day, it seems to me that the real motivation for this 
is to eliminate this idiom:

$foo =~ s/^ *//g; # or however YOU do it

Is that worth the cognitive load introduced by a "trim" function that 
haves differently in two ways than one familiar with chomp expects? Idk.

To summarize this, do not forget about chomp. It's not perfect, but some 
of us have learned to not hate it.


On 3/26/21 7:14 PM, Leon Timmermans wrote:
> On Sat, Mar 27, 2021 at 1:13 AM Christian Walde
> <> wrote:
>> On Sat, 27 Mar 2021 01:08:04 +0100, 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 think this comes down to the same issue as with the "new defaults" thing.
>> Originally no-strict perl was intended by Larry to be easier and approachable for newbies and literally called "baby perl". Nowadays there's a lot of people claiming we must enforce strict as hard as we can because it's best for newbies.
>> I suspect people with different expectations of trim and thoughts about chomp come more often than not from different generations of learning.
> I believe this is largely a difference between whipuptitude perl and
> manipulexity perl. chomp's semantics make more sense in the former
> than in the latter IMHO.
> Leon

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About