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