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

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

Thread Previous | Thread Next
From:
Jarkko Hietaniemi
Date:
October 31, 2001 08:18
Subject:
Re: [PATCH] core-only patch for clamp/readonly hashes
Message ID:
20011031181816.P18289@alpha.hut.fi
> Depends what it means - "restricted" is suitably vague ;-)

I've studied politicians :-)

> >                add     delete  add     delete  access
> >                old     old     new     new
> >READONLY        -       -       -       -       +
> >restricted      +       +       -       -       +
> >normal          +       +       +       +       +
> 
> Hmm, then I think what I have been calling READONLY is what you have
> labeled restricted above.

No wonder we have been jostling about the nomenclature, then...

The problem is finding a word that describes that one can add
*or also delete*, but only within the set of allowed keys.

Or should we even separate the add and delete rights?

               add     delete  add     delete  access
               old     old     new     new
RWD             -       -       -       -       +
RW              +       +       +       -       +
RD              +       +       -       +       +
RWD             +       +       +       +       +

Hey, this is starting to look like an ACL system...

> %hash = (foo => 1, bar => 2);
> Access::Readonly(%hash);
> 
> $hash{foo} = 3;     # okay allowed key
> $hash{foo}--;       # okay allowed key
> $hash{baz} = 7;     # error - not an allowed key
> if ($hash{baz}) ... # error - not an allowed key
> exists $hash{baz};  # error - not an allowed key
> delete $hash{baz};  # error not an allowed key
> exists $hash{foo};  # true
> delete $hash{bar};  # okay
> exists $hash{bar};  # now false
> if ($hash{bar}) ... # okay - allowed just not there
> 
> That is READONLY fixes the set of allowed slots (keys for a hash,
> upper bound for an array) but not the values.

Yup, that's what I called "restricted" and Jeffrey called "clamped".

Don't forget that one can delete $array[$element].  And should
restricting/freezing/claming an array also disable setting new
elements of the array?  I think so.

> One can of course fix the values (without anything extra) thus:
> 
> %hash = (foo => 1, bar => 2);
> Access::Readonly(%hash);
> Access::Readonly($_) foreach values %hash;
> 
> $hash{foo} = 3;     # error - modify readonly value
> $hash{baz} = 7;     # error - not an allowed key etc. etc.

> delete $hash{bar};  # ????

Okay with just "restricted" (no "readonly"), croak with "readonly"
(with or without "restricted").

> So if we do add the feature I would rather it was a property of the value
> and not the hash. That way one could mark some values as "stuck" while

We could have both.  As SvREADONLY() now has semantics for scalars,
and we are discussing extending that to aggregates, this new property
could be both for scalars and aggregates.

> allowing others to come and go/change.
> For example:
> 
> %nick = (Date_of_birth => ...,   # fixed and non-deleteable
>          Location      => ...,   # must have one, but can vary
>          Mobile_number => ...,   # optional
>         );

I like this idea.

> (Aside - is Storable going to save/restore RO-ness ???)

Well, probably yes, once we first implement RO-ness...

-- 
$jhi++; # http://www.iki.fi/jhi/
        # There is this special biologist word we use for 'stable'.
        # It is 'dead'. -- Jack Cohen

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