Front page | perl.perl5.porters |
Postings from March 2021
Re: Let's talk about trim() so more
From: B. Estrade
March 27, 2021 00:54
Re: Let's talk about trim() so more
Message ID: email@example.com
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,
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
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
> <firstname.lastname@example.org> wrote:
>> On Sat, 27 Mar 2021 01:08:04 +0100, Ricardo Signes <email@example.com> 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.