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

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

Thread Previous | Thread Next
From:
Michael G Schwern
Date:
November 1, 2001 10:06
Subject:
Re: restricted hashes, and other readonlyness (was "clamp...")
Message ID:
20011101130600.B7467@blackrider
There seem to be many "wants" here for read-only hashes:

    1) protect against key typos
    2) protect against other parts of the program putting random crap
       in your hash (usually objects and subclasses)
    3) provide a constant hash (ie. fixed keys, fixed values)

#1 is the "any read access to a key which doesn't exist is an error".

#2 are provided by a hash with a fixed keyset, nothing more,
nothing less.  delete(), exists(), keys() all work like regular
hashes.  This is the basic struct.

#3 is just a fixed keyset plus disallowing delete() and 
$locked{$key} = 'foo';


On Thu, Nov 01, 2001 at 07:33:49AM -0800, Jeffrey Friedl wrote:
> 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.

I agree whole heartedly with this.  Hashes, read-only or not, are
still hashes.  The following code:

    delete $hash{some_allowed_key};
    print "Nope" unless exists $hash{some_allowed_key};
    print "Nope" unless grep { $_ eq 'some_allowed_key' } keys %hash;

Should work the same on all built-in hashes.  Unless we have a case
where delete() is not allowed at all.  I'm losing track.

The drop-in argument is all the more important when you consider the
case of passing around a read-only hash (or whatever we're calling
it).  If I have my %struct and I want to hand it off to some function
that just works on hashes, it just should work without special code to
check if it's a struct or not.

Regarding using keys() to ask what's allowed: Consider the utility of
this.  Given that a %struct has a fixed keyset, how often are you
going to want to know what keys are allowed?  How often are you going
to want to know what keys are uninitialized?  Is it worth confusing
the semantics of keys() for this (consider the extra documentation)?
What's wrong with an XS allowed() function?

Finally, the argument that we can shave a few bytes of memory by
adding a few inconsistencies into the implementation seems a throwback
to pseudo-hashes.

We made these mistakes with 5.005 pseudo-hashes.


-- 

Michael G. Schwern   <schwern@pobox.com>    http://www.pobox.com/~schwern/
Perl6 Quality Assurance     <perl-qa@perl.org>	     Kwalitee Is Job One
Hold on while I slip into something a little more naked.

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