Front page | perl.perl5.porters |
Postings from October 2001
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