Front page | perl.module-authors |
Postings from November 2003
A. Pagaltzis writes:
> * Smylers <Smylers@stripey.com> [2003-11-03 00:40]:
>
> > ... safety isn't really the point --
> > Wx::StaticBoxSizer can safely be inherited from,
>
> Well, you can't safely store your own attributes in a $self hashref
> provided by a superclass;
True, but that's 'normal' Perl inheritence for you.
> putting them in an out-of-band data structure lets you.
>
> Maybe that's the name you're after - Class::OutOfBandAttributes.
Yeah; it's probably the best thing anybody's come up with so far. It's
a bit long, but that doesn't matter because it only ever gets used in a
use base line, not scattered many times throughout a program. Thanks.
> > That's a good reason; that would be a reason for all Perl objects
> > doing all of their attributes like that (well, except when
> > subclasses want to access their parents data ...).
>
> Then the subclasses should use accessors.
Possibly. I think of accessors mainly being for users of a class, and
that providing them is encouraging individual attributes to be got and
set. For some classes that's not what I want, or not even possible.
But a subclass is more intrinsically linked with its parent than a mere
user is, so it seems reasonable for a subclass to use 'private' data
that a class user wouldn't.
> Just like you do in any modern OO-aware language.
Exactly. And that's one of the reasons why I choose to use Perl rather
than any of the other modern OO-aware languages!
> > My module is not intended to be a general implementation for people
> > who want inside-out objects! Anybody wanting such a module will be
> > disappointed by trying to use my module!
>
> Indeed, as I noticed by looking at it again, it does things quite
> differently.
I'm glad we're agreed on that!
> > > 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!
>
> You could just have people pass a default to get_attribute.
>
> for(@{$self->get_attr('foo', [])}){ ... }
>
> If exists() shakes its head, that's what they get.
Possibly. That's effectively what attribute_list() is doing, but it's
special-cased for providing a default of (). Now you bring it up
though, I can think of circumstances where getting the array reference
rather than a list of values would be useful -- I'll add in a wantarray
test and return that or [] in scalar context.
> Or maybe you want to make this a distinct get_attr_or_default().
I can't really think of situations where other defaults would be
improved by specifying another parameter rather explicitly checking for
the return result (even without the // operator) -- again that's
something you'd have to do anyway with a 'normal' hash-ref-based object.
I just created these methods so as to provide equivalent functionality
to what's available with a hash-ref, not aiming to do more.
> It was mostly a misunderstanding. I didn't take a close enough
> look at your code to see the difference before shooting off about
> inside out objects.
Fair enough!
> I guess in the absence of Class::InsideOut, having
> Class::OutOfBandAttributes as a band-aid isn't a bad idea.
OK, I'll release it with that name. If another module materializes that
does all this and more then I'll change the docs of my module to
recommend that people use the 'better' one instead!
Smylers
Thread Previous