Leon Timmermans via RT <bug-Readonly-Tiny@rt.cpan.org> wrote:
Show quoted text> Queue: Readonly-Tiny
> Ticket <URL:
https://rt.cpan.org/Ticket/Display.html?id=111169 >
>
> On Wed Jan 13 17:11:12 2016, ben@morrow.me.uk wrote:
> > 1. It does not perform an assignment; it returns a readonly structure.
> > For the situations where I wanted it, this is more useful; in
> > particular, I had a bug where a Moo lazy build method was building a
> > structure that was supposed to be constant, and some other part of the
> > program was accidentally changing it. For a build method this calling
> > convention is more useful. I have also used it to assign a ro value to a
> > 'state' variable, which is impossible with C::F or Readonly.
>
> Sounds entirely reasonable to me. In Const::Fast I tried to make a
> drop-in replacement for Readonly, it's not my first choice of
> interface either.
Yup, I thought that was the case. I can see why Readonly had to have
that interface, given a 5.6 implementation, but it's not a good one.
Show quoted text> > 2. It does not attempt to clone deep structures. C::F not only clones
> > the assigned structure (...sometimes), it makes multiple copies of any
> > internal cross-references, turning the whole structure into a plain
> > tree. This is not always useful, and, IMHO, not part of the job of a
> > 'readonly' module.
>
> Cloning deep structures is because it may share a part of the graph
> with something else that shouldn't be read-only. Breaking internal
> cross-references is unintentional and I consider that a bug.
Hmm... I tend to assume that if I asked for something to be made
readonly, I meant it, and if it points to something that shouldn't have
been, that's my fault. I have been considering some sort of selector
function interface, but identifying where we are in the structure in a
sensible fashion isn't straightforward, and I haven't needed the
functionality, so I haven't bothered.
Show quoted text> > 3. It has a readwrite function; I was not sure about including this,
> > given its potential danger, but it is useful in cases like a shared
> > cache structure, that should normally be readonly to catch accidental
> > modification, but which occasionally needs updating.
>
> I would recommend against that functionality (in fact, I think I've
> argued on p5p for removing that possibility from
> Internals::SvREADONLY. Most read-only values in perl are depending on
> staying read-only for correct operation.
There are strong warnings in the documentation against using it
carelessly, and an at least minimal non-foot-shooting check against
PL_sv_{undef,yes,no}. Also, recent versions of perl seem to have a
separate core-only readonly flag, which can't be unset from Perl.
Ben
RT for rt.cpan.org