Tim Bunce <Tim.Bunce@pobox.com> wrote: |> > >Nick Ing-Simmons <nick@ing-simmons.net> wrote: |> > >|> - why do we need new flag rather than SvREADONLY ? |> > > |> > >As I mentioned in the original post, clamping is different from |> > >readonly. It seems to me that a readonly hash would mean that no |> > >changes would be allowed at all, including to its values. |> > |> > The writability of the values could/should be controlled by the |> > SvREADONLY bit of the value SVs. |> > |> > Thus to get "clamp" just set flag on HV, to really lock it down |> > set it on the values then set on HV. |> |> FWIW, I agree with Nick entirely. Well, there are tradeoffs to his proposal, and they should at least be mentioned..... With Nick's proposal, when wanting to make a hash readonly, you'd have to iterate over all keys, marking the values as readonly. If you wish to remove the readonlyness, you then have to iterate again to unmark the values (perhaps unmarking values that themselves had been independently marked readonly -- a big problem). It also means that if an attempt is made to change to a hash element, you must first track down the value and check it. However, if you use SvREADONLY on an HV to mean that the hash is readonly, you skip the need to iterate, and can bail on an errant update immediately, without having to track down the particular value. The cost, though, is that you need to use another of the unused flag bits for clampedness. The efficiency in the exception case doesn't seem very important, since it's the exception case. But the requirement to iterate over all keys to make something readonly, and the inability for individual values to keep their own personal readonly state across their enclosing hash's being made non-readonly, seem important issues to me. It may well be that the choice for not using an extra bit are obvious to someone more familar with Perl internals than I, but since I'm not familiar, I hope you'll forgive my bringing these issues up. JeffreyThread Previous | Thread Next