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

Re: [PATCH for discussion] clamp, round #2

Thread Previous | Thread Next
Nick Ing-Simmons
August 1, 2001 07:45
Re: [PATCH for discussion] clamp, round #2
Message ID:
Jeffrey Friedl <> writes:
>Nick Ing-Simmons <> wrote:
>|> I seem to be missing something here. I agree they are orthogonal, and need 
>|> more than one bit. I am proposing that a "read only hash with N members"
>|> uses N+1 bits and a "clamped hash" uses 1 bit - thus:
>|> A. Setting "the" bit on the HV to say "keys are fixed" (i.e. clamp).
>|> B. Setting "the" bit on the SVs that are the values to say "cannot change value".
>This is exactly what my patch does.
>Clamp::Keys(%hash) does "A" above.
>Readonly::Hash(%hash) does both "A" and "B".
>If you wish to do "B" only, one may with each() and Readonly::Set($hash{$key})


>SvREADONLY, and only SvREADONLY, is used for the above.

Fine. So we have "clamp keys" sorted ...

>What I referred to as orthoginal in the implementation (although to the
>user, quite related) is the ability to do Clamp::Access(), which causes
>access to non-existant/unapproved keys to be an error. It's this flag on
>the HV that requires another bit.
>The separate actions of clamping access and clamping keys are described in
>the docs, although obviously not well enough. At least I made sure to put
>the docs at the head of the patch:

I have re-read that and I still don't get what "Clamp Access" means or why it
is necessary given "Clamp keys".

From the docs:

  A hash can have its keys clamped. This means that keys may not be added
  or deleted. This is a subset of making a hash readonly.

  Unrelated to either readonlyness or a hash's keys being clamped, you can
  clamp access on a hash to disallow access of "non-approved" keys. A key is
  "approved" if it exists at the time a hash's access is clamped and is not
  later deleted at a time its access isn't clamped.

I don't see why that is (a) unrelated or (b) necessary.

Give an "Clamped Keys" hash then as keys cannot be changed (by definition
of clamped keys) then the keys _now_ are the same as when it was clamped
so any attempt access a key which is not there is a "non-approved" 
access so is an "error" - but it is already an error by clamped-keys-ness
as it would be "adding" a key.

So please explain again when one would want a "Clamped access" hash and 
why it cannot be emulated with just a "clamped keys" hash and/or readonly.

>|> Then explain why this cannot be done with 'magic' ;-)
>I made my position on magic clear in the note to which you replied:

>Maybe it's that clarity that accounts for your ";-)", but in case you
>really want the explaination, I'll reiterate (cool -- I've used that word
>twice now in a week):
>   "I still need to be educated about magic types, etc.. "

That is what the ';-)' was for. 

It seems to me that the whole "clamped" stuff is exactly what "magic" is 
for. So re-inventing the hooks in an ad. hoc. manner for "clamp" is 
like suggesting hexagonal wheels when we already have octagonal wheel

"magic" calls C code when you (attempt to) access something. 
e.g. "tie" adds magic that pushes things onto stack and calls methods
when access is attempted. The cost of the 'magic' part is low,
the high cost of 'tie' is the stack twiddling and the method lookup.

(In my analogy "tie" is a scheme to strap some triangles onto an octagonal 
wheel to make a square wheel ...)

>BTW, I was talking to Jeremy Zawodny and he thought that since global symbol
>tables are hashes, one could clamp keys/access to a package, which would
>then catch stuff like
>        if ($Some::Package::Quite)
>when one meant
>        if ($Some::Package::Quite)
>This currently doesn't work because of my aformentioned ignorance of
>magicness (and %:: is magic), 

Nick Ing-Simmons

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