--- Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 27, 2003 at 11:00:17AM -0800, Michael Lazzaro wrote:
>
> > resize => (1024), # internal blocksize (in indexes)
> > # by which array expands?
> > resize => { $_ * 2 }, # or via closure, based on current
> size?
>
> I think you're making too many assumptions about the internal
> implementations
> of arrays here.
> At least, I'm hoping that the innards will be flexible enough to let
> me
> do different things, such as request sparse arrays by default
>
> > 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.
>
> 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
const int * ptr; /* Variable pointer to unchanging elements. */
and
const int const * ptr; /* Unchanging pointer to unchanging elements */
versus
int const * ptr; /* Unchanging pointer to variable elements */
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.
(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.
Far better to have
LockedArray, LockedString, LockedNumeric, LockedBarnDoor, LockedMouth
than to have
FrozenArray, StaticString, ConstNumeric, LockedBarnDoor, SealedLips
(Unless this is one of those gobhoblins... ?)
=Austin
> If array indexes have a concept of exists distinct from defined, then
> several
> more graduations appear.
>
> Nicholas Clark
