Front page | perl.perl5.porters |
Postings from March 2021
How would you trim $_, or an array or a hash or an array of hashes? Perl already has an excellent orthogonal method for manipulating strings in various ways: regular expressions. By adding trim() and no doubt the all important *trimButKeepLeadingLeftTabs*() function so crucial in manipulating make files we cover one of the crown jewels of Perl - the easy use of regular expressions - with an old dust sheet taken from a lesser language. Regular expressions are just too powerful - better hide them to pretend we do not have them so we can look more like another language: then when the denouement comes we can pretend we made an effort. Trim and all its infinite variants surely belong in CPAN where people can use them or not as they wish. In the core they make things much worse - yet another function to learn, a function that has its own paradigm inconsistent with other such functions, a distraction from a core component of Perl namely regular expressions, just another piece of syntactic sugar like so much of that runaway success story called Perl 6: Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery <https://www.brainyquote.com/authors/antoine-de-saint-exupery-quotes> On Fri, Mar 26, 2021 at 9:29 PM 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 > <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. > > > -- Thanks, Phil <https://metacpan.org/author/PRBRENAN> Philip R Brenan <https://metacpan.org/author/PRBRENAN>Thread Previous | Thread Next