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

Re: trim vs trimmed revisited

Thread Previous | Thread Next
From:
demerphq
Date:
February 25, 2022 16:01
Subject:
Re: trim vs trimmed revisited
Message ID:
CANgJU+XCOddrb1REN4vLR79a2Z3p47qw1d_jYKvcaUQJLEJc_g@mail.gmail.com
On Fri, 25 Feb 2022 at 16:09, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Fri, 25 Feb 2022 01:24:00 -0600
> David Nicol <davidnicol@gmail.com> wrote:
>
> > IMO trim should operate in place in void context and return the
> > substring in nonvoid context. Optimizing
>
> Functions that do materially different things depending on context have
> been a constant annoyance to newbies and experts alike, ever since the
> language was first created. They are commonly agreed to be one of the
> worst mis-features of the entire language.
>

One of them for sure.


>
> What does this do?
>
>   sub shortname {
>      my $self = shift;
>      return trim( $self->{fullname} );
>   }
>
> Does it mutate the object instance, or not? Perhaps it depends on the
> caller.
>
> Maybe far away in a script somewhere many files away:
>
>   printf "My shortname is %s\n", $user->shortname;
>
>   $user->shortname;
>   printf "Fullname is now %s\n", $user->{fullname};
>
> Oops. We just broke the object.
>
> This sort of "spooky action-at-a-distance" makes it hard to build
> robust code and reason about its behaviour in small modular pieces.
>

I agree with all of this. Various context related issues with sort
especially come to mind.

But i'd like to note that in previous discussion it has not been clearly
stated as  "*context dependent* in place edits are bad" it has simply been
presented that "in place edits are bad". At least I don't recall *that*
component of the objection being made clear at all.

It would have saved a lot of discussion if the *context dependent*
component of the objection was made clear (at least in a couple of contexts
where I reacted to this statement it either wasn't stated at all or wasn't
clear to me). Also I believe comparisons were made to chop and chomp,
neither of which return the string being chopped or chomped, which
further muddied the water. Eg, we /could/ (not saying we /should/) make
trim return a count of characters removed. It would suck, but it
wouldn't be context dependent.

As we can DTRT with

$var= func($var);

then we get to have cleaner syntax and the performance win.   Might be nice
to have a standard way to implement this. At $work we often had XS things
similar to the following:

sub whatever_inplace {
   # do stuff to $_[0];
   return;
}

sub whatever {
    my ($str)= @_;
    whatever_inplace($str);
    return $str;
}

Anyway, thanks for explaining the objection in a way that is clear. I fully
agree with the rationale you posed.

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

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