#!/usr/bin/perl
use warnings;
use strict;
use feature qw{ say };

use Readonly;
Readonly my @arr => qw( a b c );

say "@arr";
eval { $arr[1] = 'B' };
say "@arr";
eval { splice @arr, 1, 1, 'C' };
say "@arr";

__END__
Output:
a b c
a b c
a b c
[download]

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

Currently, unlike scalars, Readonly's arrays and hashes are still based on tie(). This splice conundrum is one of the last things keeping me from moving totally away from tie magic (which, besides speed, has its own problems some of which are sitting on RT) on modern perl. I'd hate to get rid of one set of issues only to introduce a totally new set.

Edit: I'm the maintainer of Readonly, btw. And by 'modern' I mean v5.8.8 or higher.

even though the container is immutable

It isn't. It looks like splice doesn't care about SvREADONLY at all (but unshift does). You can extend such a list an array via splice:

@a = qw[a simple list];
warn join ' ', @a;               # "a simple list"
Internals::SvREADONLY(@a,    1); # Make the list RO (doesn't matter he
+re, actually)
Internals::SvREADONLY($a[1], 1); # Make our target element RO (double 
+sure!)
warn '@a is ' . (Internals::SvREADONLY(@a) ? '' : 'not ') . 'read-only
+';
splice(@a, 1, 1, qw(not quite readonly));
warn join ' ', @a;               # "a not quite readonly list"
warn '@a is ' . (Internals::SvREADONLY(@a) ? '' : 'not ') . 'read-only
+';
unshift @a, qw*this is*;
__END__
a simple list at 1167665-reply.pl line 2.
@a is read-only at 1167665-reply.pl line 5.
a not quite readonly list at 1167665-reply.pl line 7.
@a is read-only at 1167665-reply.pl line 8.
Modification of a read-only value attempted at 1167665-reply.pl line 9
+.
[download]

This is a bug (incomplete implementation, maybe also a design issue). It looks like Internals::SvREADONLY has been tacked onto, not "bolted through" the perl source

Yes, you're correct. It's supposed to be immutable but isn't. I only picked it up again yesterday but all the array related functions I've tried pass (by failing) except splice. I'll take this to RT in the morning and let them sort it out. :)

Thanks! Good to have a second or third pair of eyes.

A quick look at the source (pp_splice() in pp.c), shows that it doesn't check the state of the readonly flag. a simple 1 or two line patch should fix it.

That said, I cannot remember the last time I accidentally modified the contents of an array I didn't want modified, so it's a moot point as far as I'm concerned.

Indeed, if some module or api gave me an array that was readonly and I wanted to modify it, I'd just turn the flag off and do it anyway.

This certainly isn't anything that would stop me from replacing the use of Readonly if I encountered its use in some module I wanted to use.

But different folks ...

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.