> * Orton, Yves <[EMAIL PROTECTED]> [2003-11-03 17:27]:
> > Thats because the apporach you are comparing it to is flawed.
> >
> > foreach (@{$self->{foo}||[]}) { ... }
> >
> > is the correct way to spell that I think.
>
> Actually, no. See below.
>
> > > If the 'foo' attribute hasn't been set to anything, then you
> > > want an empty list to iterate over. With version C, that's
> > > what you get.
> >
> > No. If $self->{foo} is undef you get an error with version C.
>
> You're forgetting autovivification. If $self->{foo} is undef it
> is coerced into a appropriate reftype.
Gah. It seems you are correct. The rules for when autovivification happens are a little byzantine I think.
IMO this usage is a single level FETCH and not a STORE or a multilevel FETCH and as such should NOT autovivify. In fact the behaviour is inconsistant. Sometimes it autovivifies, sometimes not.
Consider:
D:\>perl -e "use strict; use warnings; my $x; if (@{$x}) { print}"
Can't use an undefined value as an ARRAY reference at -e line 1.
D:\>perl -e "use strict; use warnings; my $x; for (@{$x}) { print}"
D:\>perl -e "use strict; use warnings; my $x; for (@{undef()}) { print}"
Can't use an undefined value as an ARRAY reference at -e line 1.
D:\>perl -e "use strict; use warnings; sub u { undef } my $x; for (@{u()}) { print}"
Can't use an undefined value as an ARRAY reference at -e line 1.
So you cant just assume that for (@{EXPR}) {...} is going to be ok if EXPR resolves to undef. If EXPR is a function call return then it isnt safe.
Anyway, this is all just after the fact explanations that I am providing out of embarrasment.
:-)
> > Nah, just make the get_ autopopulate an undef attribute on
> > fetch. That way its not done unless is actually being used by
> > external code.
>
> Yes, but what with? You can't know whether the attempt to access
> an undef attribute is inside an array deref, a hash deref,
> outside any deref contexts at all, or wherever. That's why I
> proposed having a get_attr_with_default.
Ahah. Yeah good point...
> Well, to be clear: I don't like the idea.
>
> Because just as you said, having a good ::InsideOut would kill
> *all* birds with one stone - what this module does and what
> several others as well do (modules like the one that ties the
> hash and prepends the package name on all accesses to a
> traditional hashref $self - I can't remember what it's called).
>
> On the other hand, we _don't_ have ::InsideOut so being
> pragmatic, I'm saying that maybe it's not a bad idea to have this
> in the meantime..
Well, maybe there are ways around the problems mentioned before. I think there are. Im just not sure yet.
Yves
