Front page | perl.module-authors |
Postings from November 2003
> * Orton, Yves <yves.orton@de.mci.com> [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
Thread Previous
|
Thread Next