I'm moving this to perl6-language-data
Bart Lateur wrote:
>
> On Tue, 29 Aug 2000 20:21:39 +0800, Kenneth Lee wrote:
>
> >oday this just came up to my mind, we could have a pragma that disable
> >`autovivification' of hash and array keys. Consider the follow code snippet:
> >
> > @arr = ( 0..9 );
> > %hash = ( a=>1, b=>2 );
> >
> > {
> > no autovivify;
> > $arr{10}++; # both are
> > $hash{c}--; # fatal
> > }
> >
> >this way we can eliminate the need to tie any variables to special classes
> >and catch invalid accesses.
would this be a good attribute?
my @arr:closed = (0..9)
or a better container type altogether
my closed_array @arr = (0..9)
where closed_array inherits most normal functions but the autovivify ones
> Would it? Hmmm... One of the problems is with fields of, for example,
> objects. There, not just autovivification, but simply access of a
> nonexistent field should cause a complaint. That is a problem that your
> proposal doesn't solve.
>
> But, there's at least one function where I would want to disable
> autovivification: for parameters to exists().
>
> Witness:
>
> use Data::Dumper;
> unless(exists $hash{foo}{bar}{baz}{quux}) {
> print "Nope.\n";
> }
> print Dumper \%hash;
> -->
> Nope.
> $VAR1 = {
> 'foo' => {
> 'bar' => {
> 'baz' => {}
> }
> }
> };
>
> This pollution of my data structures can be pretty annoying. I'd like
> this not to ever happen.
>
> Perhaps this should even be extended to all data accesses not in a LHS
> context.
Another possibility would be if C<exists> was allowed to parse its argument
itself rather than relying on argument regularization to do it for it. If
it did its own, it could send back NO as soon as it found a nonexistent part.
This goes for C<defined> too of course.
