Tim Bunce <timbo@dansat.data-plan.com> writes: >> > >> >Could use the magic list (xpvhv.mg_magic) as a way to store random >> >bits of extra info. Speed isn't an issue here as it would only be >> >used to adjust an error message. >> >> Speed isn't an issue for the bless is-allowed-really case. >> But speed is very much an issue for the "this is a restricted hash" case. >> Every time we add/delete a key from a hash we have to check that >> hash is not restricted. Doing an mg_find() for every such thing is too slow. >> Thus something like SvREADONLY is needed to mark restricted hashes. > >I wasn't suggesting that we stop using SvREADONLY to mark restricted hashes. > >I was just suggesting that the magic list could provide a way to indicate >why the hash is SvREADONLY so that a more specific error message could be given. But why do we take the extra memory? SvREADONLY on an HV means a restricted hash - that is the "fast" code is going to treat any HV with SvREADONLY as having restricted semantics. So if the error message mutated to mention restricted hash nature if SvTYPE said it was an HV it would not be lying. What additional information would you put in the magic and what would put it there? > >Tim. -- Nick Ing-Simmons http://www.ni-s.u-net.com/Thread Previous | Thread Next