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

Re: Let's talk about trim() so more

Thread Previous | Thread Next
B. Estrade
March 27, 2021 07:59
Re: Let's talk about trim() so more
Message ID:
On 3/26/21 11:50 PM, Darren Duncan wrote:
> Would it be scope creep to consider making the proposed built-in trim() 
> more general or customizable?
> There is already precedent in other languages including SQL where trim() 
> can take an optional extra argument that defines the character set we 
> want to trim, and if omitted it defaults to plain whitespace.
> That is, I propose trim() has an optional second argument that is a 
> regular expression fragment defining a single character class, or 
> perhaps a full on regular expression value.
> For example, these 2 have the same behavior:
>    trim($str);
>    trim($str, /\s*/);
> But then one could also alternately say something like this:
>    trim($str, /\W*/);
>    trim($str, /[abc]/);
>    trim($str, / /);

Can we just add "im" as modifiers to tr/// ? It comes with the handy 
mnemonic, "tr///im".

my $new_str = tr/$str/\s/im;

Everybody wins. tr/// (and versus regexes) is no less confusing to 
newbies and seasoned Perlers, alike.

Seriously, though this reminded me of split (and the confusion that the 
necessary first param difference with join causes - regex vs string, but 

   use strict;
   use warnings;
   use Data::Dumper ();

   my $str = q{ foo bar bang };
   print qq{old: "$str"\n};
   my $new_string = (split(/^ +| +$/, $str))[1];
   print qq{new: "$new_string"\n};
   print Data::Dumper::Dumper([split(/^ +| +$/, $str)]);


old: " foo bar bang "
new: "foo bar bang"
$VAR1 = [
           'foo bar bang'

But really I think the whole point is to consider the other string 
functions and the fact that "trim" is inconsistent with the rest of 
them; though they're all pretty much inconsistent - so is inconsistency 
being consistent? Idk. I am confused now.

And there's something I found because I was going to make an 
inappropriate PHP joke; however I was not aware this actually existed:

Somebody anticipated this day. Also it is hilariously failing 130/131 
tests, according the metacpan; but whatever. Lest we forget PHP is only 
a thing because Perl didn't have TemplateToolkit yet (personal 
assertion, anyway).

I'll end with my preference, which I get is meaningless. I really hope 
nothing comes out of this discussion other than all CPAN modules that 
implement "trim" be required to implement "tromp", including as a 
vmethod* in TemplateToolkit - which incidentally should do the opposite 
since .trim in TT modifies the value directly. This seems consistent.



* TT does not have "chomp" as a vmethod

> The idea is that users can decide for themselves what bounding 
> characters are considered garbage to get rid of.
> I realize that keeping it simple is key because after awhile we can just 
> say well use a regular s/// then to get what you want.
> The idea with my proposal is that the second argument is something 
> simple where behavior is to strip off anything matching at the very 
> start and very end of the string.
> And actually trim() should be behaving with \a and \Z or such anchors 
> and not ^ or $ anchors as traditionally understood that treat multi-line 
> strings special.
> Note that my proposal is a syntax extension so it could be ignored in 
> the first version and added later while being backwards compatible with 
> the simpler 1-argument version this discussion is mainly about.  But 
> maybe its worth doing in the first version.
> -- Darren Duncan

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About