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

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

Thread Previous | Thread Next
From:
Jeffrey Friedl
Date:
August 1, 2001 08:54
Subject:
Re: [PATCH for discussion] clamp, round #2
Message ID:
200108011554.IAA04258@ventrue.corp.yahoo.com

Nick Ing-Simmons <nick@ing-simmons.net> wrote:
|> 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.

For two distinct reasons:

   1) Even if a hash is completely readonly,
	 if ($hash{NonExistantKey})
      does not create the key, and so is permitted.
      One may want the additional ability to prohibit this kind of access
      to random keys (i.e. to flag them as an error -- my {quite}/{quiet}
      example).

   2) One may wish to prohibit the reading of non-existant keys
      w/o prohibiting the creation of them. This is similar to 'use strict'
      in that you're prohibitied from referenceing non-existant lexical
      variables, but not prohibited from creating them.

Consider a kid of hash declaration that says

   "I want this hash to have key/value pairs A=>1, B=>2,
    and additionally I want to allow people to access keys C and D, but
    not have them at the moment"

This would be:

    my %hash = (A => 1,
	        B => 2,
	        C => undef,
	        D => undef);
    Clamp::Access(%hash);
    delete $hash{C}; ## "C" is now !exists(), but is "approved"
    delete $hash{D}; ## "D" is now !exists(), but is "approved"

This way, you still allow
	if ($hash{D})


Actually, one might even go so far as to allow "approved" keys to be added
to a hash that has its *keys* clamped. This way, you could set up a hash in
which you specify
	* here are the keys that are ever allowed
	* and among those, here are the ones that I want to instiantiate now

This would change "readonlyness" of keys from a binary thing (yes, no) to a
tertiary thing (yes, no, yes for this list of keys).

I think these semantics would be quite powerful.

We could even have a way to inspect keys:
   exists $hash{$key}  -- true if the key currently exists in the hash

   defined $hash{$key} -- true if the key currently exists in the hash,
                          and has a non-undef value

   allowed $hash{$key} -- true if the key currently exists in the hash,
                          or may be added to the hash

|> 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
|> factory.
|> 
|> "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.

I suppose one could make a copy of all the current hash stuff, put it
behind a magic call, then make the few minor changes needed to support this
stuff. It seems like a lot of duplicated code to save a very small amount,
but maybe it's that kind of attitude that makes Perl so fast.

	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