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

Let's talk about trim() so more

Thread Next
From:
Scott Baker
Date:
March 26, 2021 21:29
Subject:
Let's talk about trim() so more
Message ID:
2bfb7520-ad7d-4fad-f2bd-9c7a602e2de8@perturb.org
Per the email from PSC I'm starting a conversation about the trim() 
implementation I'd like to land in core.

To get yourself up to speed: Issue 
<https://github.com/Perl/perl5/issues/17952> and Pull Request 
<https://github.com/Perl/perl5/pull/17999>

------------------------------------------------------------------------

As a starting point I'm going to repost my last comment as I think it's 
sums up my position as main author and proponent of this feature:

> Per my original comment in #17952 
> <https://github.com/Perl/perl5/issues/17952> there are many other 
> languages that implement |trim()| and *all* of them implement it as a 
> return value. Also, the vast majority of CPAN modules, and darkcpan 
> implementations do so as a return value. People /expect/ |trim()| to 
> return a value just from broader experience in other languages, and 
> modules.
>
> I can count on two fingers the number of times I've used |chomp()|, so 
> copying it's model is not my first choice. Every time I've needed 
> |chomp()| I've opted instead for my homegrown |trim()| instead.
>
> Personally I don't see a use case for in-place, but if we're requiring 
> an implementation that operates in-place it should *not* be called 
> |trim()|. I would instead propose something like:
>
>  1. |trim()| returns the value
>  2. |trimi()| (i for in-place), |trimmer()|, or as Mithaldu joked
>     |tromp()| would operate in-place.
>
> This will keep us consistent with other languages, while also offering 
> a chomp-like implementation. Awaiting further guidance from PSC as to 
> next steps.
>


Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About