> > mark the entire hash as non-autovivifying (except via future calls to
> > C<private> -- see below)
>
> This bothers me. Name an operation in perl that, when applied to a single
> element of an aggregate, affects all other elements of the aggregate
> (especially future, as-yet-unborn elements).
There are remarkably few mutating operations that are specifically
applied to container elements. Of those few, it might be argued that
all of the following affect other elements in the way you ask about:
exists (sometimes causes autovivification, which affects C<keys>)
delete (affects C<keys>)
splice (affects other element's indices)
> Random idea: Only apply C<private> to hashes, not elements. This causes
> the package name to automatically be added to the keys in the hash and
> only allows access to the hash in the current package. You can still
> autovivify elements in the hash, but they're autovivifically private.
But that undoes one of the prime motivations for C<private>. Namely,
preventing autovivification-induced errors (due to misspelling for example).
> > The C<private> keyword could also be applied to subroutines, to restrict
> > where they may be called. Access rules similar to those for private hash
> > entries would apply:
>
> I'd think this too would fall out of delegation.
Yes, delegation could be used to handle this -- albeit much less Lazily
than a simple prefix -- but only if it's possible to make some
attributes private and other's not.
Damian
