On Fri, 26 Mar 2021 22:28:48 +0100, Scott Baker <scott@perturb.org> wrote: > > 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 and Pull Request > > 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 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: >> trim() returns the value >> 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. > The current best-value suggestion would be to do both imo because there is SOME value for a modify-in-place version for short scripts. So imo: While having ONLY a modifying version is WORSE than not having any version; having BOTH a modifying and a non-modifying version is BETTER than not having any. Frankly, we just need someone from PSC to tell Scott to go ahead with the latter, and put out a call figuring out the best combination of names. And i find it ... less than optimal to string him along further like this. https://i.imgur.com/Cfd8AYT.jpg -- With regards, Christian WaldeThread Previous | Thread Next