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

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

Thread Previous | Thread Next
From:
Nick Ing-Simmons
Date:
November 3, 2001 05:27
Subject:
Re: restricted hashes, and other readonlyness (was "clamp...")
Message ID:
20011103132645.664.7@bactrian.ni-s.u-net.com
Jeffrey Friedl <jfriedl@yahoo.com> 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
http://www.ni-s.u-net.com/


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About