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

Re: [PATCH] core-only patch for clamp/readonly hashes

Thread Previous | Thread Next
Nick Ing-Simmons
November 1, 2001 05:03
Re: [PATCH] core-only patch for clamp/readonly hashes
Message ID:
Rafael Garcia-Suarez <> writes:
>> So why make exists an exception to the rule ? Surly people can mistype
>> the element name passed to exists just as easily.
>That's what NI-S was saying : "exists $hash{baz}" fires an error on a
>non-existing key. But in this case an API is needed to know what's the set
>of allowed keys,

Perhaps. But enumerated hashes are approx. equivalent to C structs
(this is problem we are trying to solve). C does not have a way
to determine at run time the members in a struct - rather the code
should only use members that exists.

>or perhaps only to know whether some key is allowed. What
>will this API do with regular hashes?

NI-S is also saying that keys %enumerated_hash should return the allowed keys.

>I'm a little confused by the distinction between 'existing keys' and
>'allowed keys'. Please excuse this naive question from someone jumping
>into this threads : can't those two notions be merged, for
>simplicity? (In this case deleting a key from a restricted hash will be
>always disallowed). In other words: what is this distinction useful for?

Disallowing deletes would make the analogy with a directory without
write permission more exact. I could live with it.
We can presumably still store an undef in that slot - so most algorithms
will still work. We just loose the luxury that while a normal hash allows
the "exists but not defined" case, that would not be portable to
an enumerated hash.

It would also make hash case closer to the array case - we do not really
have/want array entries which do not exist.

Nick Ing-Simmons

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