develooper Front page | perl.module-authors | Postings from November 2003

RE: Class::FakeAttributes -- Opinions Wanted

Thread Previous | Thread Next
From:
Orton, Yves
Date:
November 6, 2003 10:41
Subject:
RE: Class::FakeAttributes -- Opinions Wanted
Message ID:
71B318898201D311845C0008C75DAD1C08961378@defra1ex2
> * 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About