On Mon, Jan 27, 2003 at 01:02:28PM -0800, Austin Hastings wrote: > > --- Nicholas Clark <[EMAIL PROTECTED]> wrote: > > On Mon, Jan 27, 2003 at 11:00:17AM -0800, Michael Lazzaro wrote:
> > > locked => 1, # read-only, can't store new values > > > > There was a discussion on p5p about "restricted hashes", and what one > > might > > want. Even for arrays I can think of at least 2 levels. Er, I think I meant "I can think of 2 levels, and there may be more" > > 1: everything locked - no new elements, existing elements treated as > > read only > > 2: size locked - you can't extend (or shrink) the array, but you can > > add/remove elements > > > > How bizarre. When you said you could think of two levels, I immediately > thought of two levels, but mine and yours aren't the same. I thought of > "totally read-only" and "content-locked" -- expanding/contracting is > okay, but no updates. (Think of implementing a stack, say.) > > Maybe this is my C background coming out. The difference between Hmm. I have a C background too. > Anyway, I guess "locked" means different things to different folks. > Probably this shouldn't be core -- it should be easy enough to code up > a standard set of permutations. Yes, although it may be useful to have the functionality in core. Then again, perl5 has to do restricted hashes in core to have any hope of doing it with usable speed, whereas parrot is designed to allow perl5 slow perl5 goodies such as tieing and overloading to have no additional calling overhead. > (OTOH, it's not unreasonable to talk about a standard set of methods > for this stuff, so that all those post-facto implementations speak the > same language. Yes, although I suspect that the details of the concepts, let alone the names, can be deferred until later on. Having subroutines and objects would be nicer. Nicholas Clark
