Front page | perl.perl5.porters |
Postings from March 2021
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
digress):
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)]);
Output:
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:
https://metacpan.org/pod/PHP::Strings
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.
Cheers,
Brett
Notes:
* 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