Front page | perl.perl5.porters |
Postings from November 2020
On Fri, 27 Nov 2020 04:51:29 +0100, Andy Xiao <xyf.xiao@outlook.com> wrote: > Apparently everyone like trim, what argue is since perl built-in function is already a bit mess, someone won't add >this burden . How about consider a "default" pragma: Break all built-in functions into several classes, like CoreScalar, CoreList, CoreIO, UserInfo, NetworkInfo, etc. >every perl program auto load all above classes except user explict say no use ....... > Since it may be a big job, putting trim into core first is not a big problem. >From: Christian Walde <walde.christian@gmail.com> > Sent: Thursday, November 26, 2020 9:05 PM > To: Vlado Keselj <vlado@dnlp.ca> > Cc: Tony Cook <tony@develop-help.com>; demerphq <demerphq@gmail.com>; Scott Baker <scott@perturb.org>; >Perl5 Porters <perl5-porters@perl.org> > Subject: Re: Looking for someone to adopt adding trim() to core >> On Thu, 26 Nov 2020 13:51:56 +0100, Vlado Keselj <vlado@dnlp.ca> wrote: > >> >> 1050 distributions and 1659 cases! Wow, that is a strong support for >> "trim". >> >> It is interesting that some of those cases use /g option, which trims all >> lines. This could be a candidate for the second argument of "trim". >> >> I would guess that not even all alternatives are counted, like: >> s/^\s*(.*)\s*$/$1/ > > Sadly there is a lot of different ways to do trim, so trim in the PR currently tries to find the most-used one >and provide that. Stuff like multi-line trim can be done fairly easily with that one by way of split map join. > > That said, as mentioned elsewhere in the thread: Once we have that it can serve as an easier template to >do such things in the future. > > Also, i recommend reading the PR in entirety as it details why adding arguments to trim() is currently not >considered desirable. :) > > --With regards, > Christian WaldeThread Previous | Thread Next