in reply to Calling splice() on Immutable Arrays

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

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Replies are listed 'Best First'.
Re^2: Calling splice() on Immutable Arrays
by SankoR (Prior) on Jul 13, 2016 at 20:48 UTC
    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.

[reply]

      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.
[reply]

        I can't say I've ever accidentally modified any data structure I didn't intend to change either. There's a real dog food problem with Readonly; I don't even use it in my own code. But apparently loads of people need to remind themselves not to do the thing they don't want to do. The fact that 350+ modules depend directly on Readonly (or depend on any of the value locking modules, actually) boggles the mind.

        Tirade incoming: I only took over the module because it was messing up code I was actually depending on and the original author of Readonly abandoned it a decade earlier. Days after I fixed that one issue, even though I made Readonly exponentially faster and more stable, my pride quickly faded and I started to regret it. I regularly get bug reports for code written for perl 5.6, I get people who want mutable copies of immutable structures, I get people who want automatic toggling for parts of a structure ('elements 3, 5, and 6 should be read-only...') part of the time ('...unless element 3 is true' at lease 3 people in the last few years want that? Why? What's the use case?), I get people who want me to work on making objects of any type immutable (because I can just insert that in MOP and inside-out objects, and blessed structures, etc.), I get people who want values to be deleted but not modified, and on and on... And no one likes to be told 'No.' Mostly I get rage filled messages when I mention dropping support for ancient perls in order to fix things that are otherwise unfixable or when I tell them I can't fix what they think is fixable. If you want to meet the most hateful and vile side of the Perl community or just generally bad programmers, take over a 16 year old module that has 30+ critical bugs that can't be resolved without breaking a good portion of Darkpan. *throws up hands* It's too early in the day to drink... :) Bright side? They've helped get a lot of really stupid edge cases like this one in perl itself fixed.

[reply]

In Section Seekers of Perl Wisdom