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

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

Thread Previous | Thread Next
From:
Nick Ing-Simmons
Date:
October 31, 2001 09:15
Subject:
Re: [PATCH] core-only patch for clamp/readonly hashes
Message ID:
20011031171513.12311.4@bactrian.elixent.com
Jarkko Hietaniemi <jhi@iki.fi> writes:
>> 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.

bounded, constrained, limited, ...

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

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

So I have been proposing what he wanted - so who wants rest of you
are calling readonly (without the delete?).
The reason I am up this creak is that I recognise the fixed-set-of-keys
as useful and I have been trying to map it into the existing SvREADONLY
bit to avoid coining new flag bits.

>
>Don't forget that one can delete $array[$element].

One could at one point get same effect (for the pseudo-hash stuff),
or was that just moonshine?

>And should
>restricting/freezing/claming an array also disable setting new
>elements of the array?  I think so.

I see that "restricting" an array limits the set of "keys" (indices)
to 0..$#array at time of restraining order.
Thus push/pop/shift/unshift/ are not allowed as they change $#array
but assignment to existing elements is okay.


>
>> 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...
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/



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