Front page | perl.perl5.porters |
Postings from February 2022
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 happens: 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 DuncanThread Previous | Thread Next