On Wed, Sep 06, 2000 at 12:05:21PM +1100, Damian Conway wrote:
> > 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)
Of those three only C<splice()> fits the bill I had in mind.
> > 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).
Why can't we just apply the same warnings on hashes as we do on
variables in Perl? Maybe a new lexical pragma:
no autoviv; # any autovivification carps (not just
# hashes)
no autoviv 'HASH'; # no new keys may spring into existence on
# any hash from this point forward
no autoviv '%hash'; # same but for a specific hash
no autoviv '@array'; # same but for a specific array
Regardless, I feel that "no autovivification" and "private-ization"
are orthogonal and should be treated as such in the languge.
private @person{'fname','lname'}; # make these private
freeze %person; # no new keys
But that's two keywords rather than one (and the second keyword isn't
that great for those people who already use FreezeThaw ;-)
-Scott
P.S. BTW, I used Text::Autoformat for the first time on this very email.
Thanks Damian!
--
Jonathan Scott Duff
[EMAIL PROTECTED]
