Front page | perl.module-authors |
Postings from November 2003
> 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.
Yves
Thread Previous
|
Thread Next