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

RE: Class::FakeAttributes -- Opinions Wanted

Thread Previous | Thread Next
Orton, Yves
November 3, 2003 08:26
RE: Class::FakeAttributes -- Opinions Wanted
Message ID:
> That's intended.  I'll make this as clear as I can:  My module is not
> intended to be a general implementation for people who want inside-out
> objects!  

I cant help but observing that perhaps it should be. Kills your bird, and
kills Aristotle's.

But thats just the obnoxious me talking. :-)

> > In general I find the interface rather ill thought out; of
> > course, if it did the job for you, hey presto.
> > 
> > But I'd prefer to do
> > 
> >     for(@{$self->get_attr('foo')}){ ... }          # A
> > 
> > rather than
> > 
> >     for($self->attribute_list('foo')){ ... }       # B
> Believe it or not, so would I!  Because, in a 'normal' class I'd just
> write:
>   foreach (@{$self->{foo}}) { ... }                  # C
> so merely using $self->get_attribute('foo') in place of 
> $self->{foo} would
> seem like the most natural alternative.  And that's what I did first.
> The only flaw with that approach is that it doesn't work!

Thats because the apporach you are comparing it to is flawed.

  foreach (@{$self->{foo}||[]}) { ... }                 

is the correct way to spell that I think.

> 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.

> (There's equivalent reasoning behind the existence of 
> push_attribute().)

But in this case its unwarranted.

  my $foo=undef;
  push @$foo,"Bar";
  print "@$foo\n";

> I don't entirely like the fact that these different methods exist.  An
> alternative would be to have the constructor initialize all array refs
> that might ever exist in an object to [].  That way version A will
> always work, because there's never an attempt to dereference undef.

Nah, just make the get_ autopopulate an undef attribute on fetch. That way
its not done unless is actually being used by external code.

> Now you've brought that up, it makes sense to add it to the 
> module docs:
> if you make sure you always initialize your array attributes then
> get_attribute() and set_attribute() are all you need; but if you don't
> then make sure you use push_attribute() and attribute_list(). 

Personally I wouldnt have get_foo and set_foo. its too much like java or VB
for me.

I prefer smart attributes that do the right thing.  Of course its quibbles
like this that are the cause the innumerable Class:: frameworks we have
kicking around, and frankly why I almost never use them.

> Well if nobody else joins in this thread then it looks like 
> the vote is
> tied, 1 each way (assuming that I count my own opinion; perhaps I
> shouldn't) ... which is a little awkward for being decisive!

Seems like you think its useful. Aristotle didnt tell you it was stupid. So
I vote keep. Not sure if that brings it to a tie vote tho..


> It isn't that I don't consider Y to be a valid problem to solve, nor
> even that I'm against the existence of a module that solves Y.  It's
> just that it isn't this module.

As I said earlier, seems to me that maybe solving both problems with one
module is the better way to go.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About