in reply to Re^10: The fallacy of the *requirement* for read-only instance variables.
in thread The fallacy of the *requirement* for read-only instance variables.
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.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^12: The fallacy of the *requirement* for read-only instance variables.
by JavaFan (Canon) on Apr 18, 2011 at 14:34 UTC | |
|
Re^12: The fallacy of the *requirement* for read-only instance variables.
by BrowserUk (Patriarch) on Apr 18, 2011 at 12:50 UTC |