develooper Front page | perl.perl5.porters | Postings from February 2022

Re: trim vs trimmed revisited

Thread Previous | Thread Next
From:
Paul "LeoNerd" Evans
Date:
February 24, 2022 15:38
Subject:
Re: trim vs trimmed revisited
Message ID:
20220224153804.6f1dd029@shy.leonerd.org.uk
On Thu, 24 Feb 2022 10:06:41 -0500
Felipe Gasper <felipe@felipegasper.com> wrote:

> > On Feb 24, 2022, at 06:36, Paul LeoNerd Evans
> > <leonerd@leonerd.org.uk> wrote:
> > 
> > Given I think we are now all agreed that mutate-in-place is a
> > terrible idea, I don't think this naming distinction needs to
> > remain.  
> 
> What gives you this impression?
> 
> The rationale for in-place modification was/is consistency with
> existing built-ins, esp. chomp. AFAICT that hasn’t changed.

chop and chomp are already well-acknolwedged as being extreme oddballs
in perl. Nothing else works quite like them - e.g. we don't do inplace
numerical ops:

  sqrt($num);

Nor are we thinking of adding void-context syntax for any other
stringy operations:

  ucfirst($title);

The *only* other two things I can think of that do an inplace mutation
of a scalar variable are

  open my $fh, ...

  $str =~ s/foo/bar/;

Of these: open is another oddball that hopefully one day we can replace
with some nicer functions like

  my $fh = fopen(...);
  my $fh = popen(...);

and regexp substitute is so syntactically different from regular
function call syntax that I feel it is allowed to act weirdly.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About