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

Re: trim vs trimmed revisited

Thread Previous | Thread Next
Darren Duncan
February 24, 2022 05:48
Re: trim vs trimmed revisited
Message ID:
On 2022-02-23 8:40 p.m., demerphq wrote:
> To paraphrase what you said above: I hear that there is some wish that Perl had 
> immutable strings.  But it doesn't, and making new functions that correspond to 
> that forlorn hope violates all existing precedents and will only sow confusion.

Depending what "immutable strings" means, Perl DOES have them, because it is a 
regular scalar type that is not a reference type.

As far as I'm concerned, the main badness for "mutable strings" is when this 

   my $s1 = "abc";
   my $s2 = $s1;
   # do something that modifies the string in $s2
   # now $s1 has also been modified

The above description is the case when $s1 was assigned some kind of reference 
type like an arrayref.  But it isn't the case for an ordinary Perl string.

For existing cases, does "chomp($s2)" or "$s2 =~ s///" etc REALLY modify the 
string itself, or does it just derive a new string and assign it to $s2?  From 
the user's perspective I would say make new and assign is what actually happens.

So unless I'm wrong about how things work, Perl's strings ARE immutable, and 
what we have here is functions or operations that assign a result to the 
variable they got their input from, which is not the same thing.

As for the original thread issue of whether to call a function that returns the 
trimmed string as a function result rather than assigning it to its argument, 
whether to call it trim() or trimmed(), I have no problem with it being renamed 
to trim(), but I also don't personally have a problem with it staying as 
trimmed().  That is assuming we don't have 2 functions one per each behavior. 
If we wanted to have both, that changes the argument.

-- Darren Duncan

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