Front page | perl.perl5.porters |
Postings from March 2021
On Thu, 1 Apr 2021 at 00:04, Scott Baker <scott@perturb.org> wrote:
> You bring up a very good point Grinnz came across when we initially
> started implementing trim(). One of the main reasons we want it done
> in core is because it's implemented so many times in other places,
> and often implemented incorrectly. Putting it in core we can
> implement it correctly and stop developers from having to reinvent
> the wheel.
The argument offered against trim was that an average programmer can
do it using regex with very little mental effort. I've incorrectly
implemented trim using regex. For example I've used /^\s*/ and taken
the return value, as in "if (/^\s*/) { }". I've used /^\s+|\s+$//
without the "g" and wondered why there was whitespace remaining. I've
confused /s and /m, and so on.
Seeing the same errors all over CPAN and even in the core modules, we
have evidence that there is some non-trivial mental effort required to
get it right. Most of the CPAN/core module mistakes are of the
harmless kind, such as using /s or \s*. Perhaps this is because the
harmful ways of trimming caused bugs, and were detected, leaving only
the harmless ones.
> In your research did you find out if people implementing trim() as a
> sub do it in-place or as a return value?
Of the two in the core modules which I found, one is in-place
(trim_whitespace in ExtUtils::ParseXS::Utilities) and the other is
return value (_trim in Tap::Parser). But most of the core modules are
using regex trimming. For example Unicode::UCD has
$type =~ s/^\s+//;
$type =~ s/\s+$//;
around line 460. Digest::SHA has
s/^\s+//;
s/\s+$//;
around line 160.
By the way, I don't have any secret methods of finding things which
other people can't access:
https://gist.github.com/benkasminbullock/a35e750690e0f97fd85e0c2a4d067b40
Thread Previous
|
Thread Next