Strings mostly act as if they were immutable in Perl 5, so my statement should be taken with care. It's only when you look at the XS or C layer that you see mutable strings:
use Devel::Peek; my $x = "foo"; Dump $x; vec($x, 0, 2) = 3; Dump $x;
Output:
SV = PV(0x1b6a088) at 0x1b8b340 REFCNT = 1 FLAGS = (PADMY,POK,pPOK) PV = 0x1b7a9a0 "foo"\0 CUR = 3 LEN = 8 SV = PV(0x1b6a088) at 0x1b8b340 REFCNT = 2 FLAGS = (PADMY,POK,pPOK) PV = 0x1b7a9a0 "goo"\0 CUR = 3 LEN = 8
You see two different strings at the same memory location, indicating mutability. Though it could of course be a newly allocated copy of the string, while the old one is gone.
Maybe it would have been better if I had talked about hashes being mutable and numbers being immutable.
My main point remains: Perl has some mutable and some immutable data types, and that all languages I know have that distinction too. So a line must be drawn, and in some contexts it might sense to create immutable objects.
In reply to Re^11: The fallacy of the *requirement* for read-only instance variables.
by moritz
in thread The fallacy of the *requirement* for read-only instance variables.
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |