Front page | perl.perl5.porters |
Postings from October 2001
> Arthur Bergman <arthur@contiller.se> writes: > > > >IMHO we should let SvREADONLY have a meaning on AVs and HVs. > > > >A Readonly hashes/array can not have any new items added or deleted to it. But > >it doesn't lock the contents. If you want to do that you can itirate over it > >and make them SvREADONLY. > > > >Arthur > > Thanks. That was essentially my position (as I recall it anyway) last time this > was discussed. > > For an HV it would also be nice to represent the case of "allowed" keys. > (For an AV I assume anything which does not raise the limit is "allowed".) > > I think that allowed (but not existing) entries in HV could be represented > by having an HE but with its SV * being Nullsv - or perhaps a pointer > to a "special" SV Just letting it be a Nullsv should be enough. > I don't think special casing "scalar keys" is necessary - the allowed keys > are counted so the existing count in the header is fine. Agreed > Personally I would be happy if allowed keys always returned true from exists > as well ... but others may differ. Agreed > What I really do not like is the 'Clamp' name - it does not suggest to me > anything vaguely like the proposed semantics. > > As I recall I was suggesting something like: > > use Access; > Access::Readonly(%h); > Access::Readonly(@a); > Access::Readonly($s); > > And we got stuck looking for a prototype that would allow/force a "reference > to anything". And now we got \[$@%] > But leaving that on one side I still prefer: > > Access::FixKeys(%h); # SvREADONLY_on(hv); > Access::FixValues(%h); # SvREADONLY_on($_) foreach values %h; > > It also seems to me that an XS module could already do this with mg.c type > "magic" - which would be faster than full "tie" as no method calls are > needed - without modification of the guts of hv.c. > You mean just croaking on a mg_store after SvREADONLY is on? ArthurThread Previous | Thread Next