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

Re: Revisiting trim

Thread Previous | Thread Next
mah.kitteh via perl5-porters
May 27, 2021 07:57
Re: Revisiting trim
Message ID:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, May 26, 2021 3:20 PM, Neil Bowers <> wrote:

> As a reminder, after a lot of discussion, there was broad agreement that we should add the capability for trimming a string, and we should keep it simple: trim whitespace from both ends of the string, with no parameterisation. Here "whitespace" means [:space:], so consistent Unicode semantics, whatever the internal encoding of the string.
> But there was disagreement on whether it should trim in place, or return the trimmed string. Maybe we should have two functions: trim() to edit in place, and trimmed() to return the trimmed string. Rik, Sawyer, and Neil were all fans of the in-place edit.
> After lots of discussion on github and p5p, the steering council also solicited input from people with a lot of experience training people and/or writing books to explain Perl.
> The end result of all of that is:
> - We think we should add a single function to Perl.
> - It should return the trimmed string.
> - It should be called "trimmed", not "trim".
> This is not a mandate, but it is our recommendation.

"trimmed" is fair, though I suspect people are going to want:

* trim also
* someone will ask for "chomped" and/or "tromp"

Please don't implement this in perl core, though. Please. Seriously.

> What convinced us on the naming issue was an example from Tom Christiansen of a large company that had a similar internal discussion, and found that people were confused over how they expected it to work, until they changed the name from "trim" to "trimmed". This also fits in with one of Larry's original desires, that Perl be a readable language. The function returns a trimmed version of its input:
> $x = trimmed $y; # "x is a trimmed version of y"
> We think that "trim" would have been the right name for editing in place:
> trim $x;
> There are only two distributions on CPAN that define a function called "trimmed", so we suspect that this will clash with less code in the wild. There are plenty of distributions that define a trim(), but not all of them perform the function we're talking about here.
> It may be tempting to claim that if we called it "trim" rather than "trimmed", then it "would just work" for the majority of people with an existing trim function (whether imported from CPAN or home-brewed). But whatever a new builtin is called, existing code would not use it by default, so everyone would have to make edits to enable it, no matter what name we give it.
> There's a related topic of namespaces for functions like this. We're deliberately not addressing that here, as we suspect it will fall out of the broader review of text/string processing capabilities, which we want completed before 5.36 (i.e. before trimmed would be included in a stable release anyway).

I think waiting on this discussion/decision is terrible mistake. All you need is a dual-life module that exports stuff via the familiar "use feature" syntax (or better under Experimental::*). Shoving things in perl core should be the absolute last stop for proven functionity that needs to be fast or for fundamental capabilities of the perl runtime needed to support useful and interesting features that are themselves implemented at much higher levels.


> We're now interested to hear what p5p thinks of this.
> Neil, Rik, Nick
Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About