develooper Front page | perl.perl5.porters | Postings from November 2001

Re: restricted hashes, and other readonlyness (was "clamp...")

Thread Previous | Thread Next
Nick Ing-Simmons
November 3, 2001 05:27
Re: restricted hashes, and other readonlyness (was "clamp...")
Message ID:
Jeffrey Friedl <> writes:
>|> Aside from the (now dead) abuse of keys - the other cause for which I
>|> am Devil's advocate is the minimalist one:
>|> One (existing) flag bit SvREADONLY
>|>  - error on get of non-existing key
>|>  - error on set of non-existing key
>|>  - delete is not allowed
>|>  - keys is just existing code
>|>  - therefore exists on deleted key is non issue
>|> I want folk to explain clearly the draw back of that
>There is no drawback to this. It's wonderful. It's a fixed-key hash,
>and is what you get with (SvREADONLY(hv) && ! SvPSEUDOENUMERATED(hv)).
>|> and why it is not sufficient for appication X.
>Seriously, again, it's the same situation I described yesterday.
>I've got these hashes (objects, if you like) that random code out
>there uses. As with many hashes that are used to implement objects,
>the set of keys this object X uses is restricted to a specific set.
>It's my hope that all the random code out there that is using the
>object is doing so nicely, but how do I know?
>"Nicely" might be defined as "if you have a {FirstName} element, there must
>be a {LastName} element". Or, it might be that "{Age}" must be numeric. Or
>perhaps "{Color}" represents a shade I like.
>Of course, there's nothing we can put into the core (at least not
>reasonably) to ensure that random code is behaving nicely with these
>semantics of "nicely". But there are some semantics that we can deal with,
>such as "use only these keys, and no others" and "don't change these
>values", etc.
>So, what *can* we do?
> *  However, we can 'use warnings' to catch some kinds of errors like:
>       $obj->{SomeTypoHear} += 1;
>Additionally, with just a few hooks in the core, we can:
> *  We can make it an error to access a key that's not approved, to catch:
>       if ($obj->{SomeTypoHear})
> *  We can make it an error to set a key that's not approved, to catch:
>       $obj->{SomeTypoHear} = 1;
> *  We can set values we don't want others to change to SvREADONLY.
>    This won't (currently) stop them from being deleted, but in any case
>    it's a good first line of defense.
>Now, if you know the situation, it may well be sufficient to just make
>the whole hash readonly. If you can do it, lucky for you.
>But at least in my world, there are many object hashes where the normal
>random code needs to deal with adding keys, deleting keys, checking for
>existance and definedness of keys, updating values, etc. This is fine, so
>long as they stick to the set of approved keys. If they don't, it'd be nice
>to hear about it.

I would like concrete examples of places where delete-ing keys is 
vital to the application. My own style of objects falls into two 
camps - objects where it is hard to pin down the keys as sub-classes 
use the object hash as a scratch pad, and objects where keys are fixed
and delete is not necessary (or desirable).

So for _me_ the fixed-keys hash is sufficent for the later, and 
none of the options help much for the former.

>The changes proposed draw a balance among the oft-conflicting
>considerations. It buys you a lot but not everything, for many situations
>but not all, but all at very little cost (except the man years going into
>this discussion :-)

There is general support for "something" - but it is not clear that 
the particular compromise in your patch addresses anyone else's problems
apart from yours. I am reluctant to "burden" perl5 with the full glory 
of the 4 possible types of hash with associated house keeping and checks
on _just_ your say-so. But if you can get the compromise "seconded" 
by other people - then a slightly cleaned up version is possible
candidate for 5.8.

>     Jeffrey
Nick Ing-Simmons

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About