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

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

Thread Previous | Thread Next
From:
Jeffrey Friedl
Date:
November 1, 2001 07:34
Subject:
Re: restricted hashes, and other readonlyness (was "clamp...")
Message ID:
200111011533.fA1FXnK41848@ventrue.corp.yahoo.com

Nick Ing-Simmons <nick.ing-simmons@elixent.com> wrote:
|> Jeffrey Friedl <jfriedl@yahoo.com> writes:
|> >Okay, I got rid of the union, the 'realkeys' stuff, added what was
|> >needed for array readonlyness, and generally tidied up.
|> >
|> >I've dropped the "clamp" nomenclature, in favor of "pseudo-enumerated" or
|> >"restricted" hashes.  (I still don't care what we call it, but I've got
|> >to use something....)
|> 
|> I think just "enumerated" will be fine - but see below.

Okay, (and I still don't care what it's called), but FYI...

   ...I thought that "pseudo-" would be useful for reminding people that
   the list of enumerated keys can change at any time if someone
   specifically goes to the trouble to unmark the hash, add/delete keys,
   then remark it.

|> >   Any access, other than exists(), with a key that is not approved results
|> >   in an error.
|> 
|>     I agree with Graham that exists on a non-approved key should also be
|>     an error.
       
Okay, not a big deal to me.

|> >   A hash that is HvPSEUDO_ENUMERATED (and not SvREADONLY) may add and
|> >   delete keys freely, but read access of a non-existant key is an
|> >   error. This is a less restrictive form of a pseudo-enumerated hash
|> >   that says "you can add elements freely, but if you're going to try
|> >   to read an element, it had better actually be there."
|> 
|>     Oh dear a 4th type which needs a name - say "Picky" :-(
|>     With your sense of bits we now have:
|>        RO EN
|>        0   0   - normal
|>        0   1   - "Picky"
|>        1   0   - non-deletable Enumerated
|>        1   1   - deletable Enumerated
|> 
|> I can see some value in 'picky' hashes but I am sure we don't have
|> concensus on them!

Perhaps not, but wanting them was the original reasons I looked at this
whole thing in the first place, and posted the first note on this topic
back on July 19th.

It's due to the discussions on p5p then, and now, that have resulted
brought us to what we have today (which is, relatively speeking, fairly
close to concensus.)

|> As far as _I_ am concerned - I am convinced we need one of the "Enumerated"
|> types. I don't really care which of the two it is.

Well, the non-deletable one is just "readonly keys", and that's not nearly
as flexible as a hash with a specific set of allowed keys. But I can also see
the value in having a vanilla "readonly-keys" hash (which would allow you to
then have a fully readonly hash if you walked the hash and RO'd the values)

I'm sure eveyone can visualize the value of a readonly hash. Let me give
you my motivation for a deltable-enumerated hash:

   Imagine, for example, any hash you use to implement an object,
   particularly one widely used in a huge system. By adding a few lines in
   the constructor to create the set of allowed keys, you then get
   protection that the rest of the system is being sociable with your hash,
   attempting to access those keys and only those keys.

   But in order for this to work correctly, all semantics related to allowed
   keys must be the same as for normal hashes.

   I guess it's like tie() -- if you do things right, random code out there
   that uses your tied variable doesn't need to care if it's a tied
   variable or not.

   Similarly, I think that someone using your enumerated-hash -- if they're
   using only approved keys -- shouldn't need to care if it's an
   enumerated-hash or not. To the rest of the system using the hash properly,
   it *is* just a normal hash.

   Like 'use strict', it doesn't change the semantics of things, but just
   disallows some things.

This natural, drop-in approach feels like The Perl Way to me, which is why
I feel that keys() should maintain the same returns-only-existing-keys
semantics.

|> The deletable variant is possibly of wider use (e.g. Michael Schwern's
|> db cache example) but I am as yet unconvinced that case is common enough
|> (compared to the 'struct' case) to be worth the extra bit and hassle of
|> defining semantics of C<keys> etc.

It's no hassel to define the semantics of keys() -- heck, we've already done
it twice :-)

We just need to pick one.

|> >   keys(), values(), and each() return data only for keys that actually
|> >   exist(). They ignore, for example, keys that are "approved" but don't
|> >   yet exist. In a scalar context, it returns the number of keys that
|> >   actually exist.  (It's left to an XS module to provide a way to get
|> >   the full list of approved keys.)
|> 
|> You know I differ on this one ;-)

Perhaps my motivation -- for the ability to define the enumeratedness of a
hash in one place and have eveything else that uses the hash properly see
normal hash semantics -- sways you a bit?

     Jeffrey

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