On Mon, Aug 13, 2001 at 06:45:30PM -0400, Dan Sugalski wrote:
> At 02:59 PM 8/13/2001 -0700, Kurt D. Starsinic wrote:
> > It doesn't seem Perlish to me for the interpreter to provide _special_
> >support for HAS-A. HAS-A is too general of a design pattern to warrant
> >pigeonholing into a particular object relationship.
>
> IS-A is in the same boat, as are object attributes. Given that those are
> already interesting problems, it seemed reasonable to include interpreter
> support for at least some HAS-A relationships for automatic delegation and
> suchlike things. I'm not proposing we jam support for all HAS-A things,
> just a few of the more common ones. Or if that's not feasable, then a
> design that has a reasonable hook so classes can intercept this for
> themselves somehow.
ISA is a much more specific relationship than HAS-A, IMHO. It is,
_per se_, about method inheritance -- and I think you'd be hard pressed
to name a class-based OO language that implements method inheritance more
generically or less restrictively than Perl. Now that we have NEXT.pm,
the only thing I can _imagine_ asking for is the ability to walk the @ISA
tree other than depth first (and I'm not losing sleep over that).
> >HAS-A can indicate
> >delegation, brokering, snooping, containing, proxying . . . and there are
> >many unique and appropriately distinct implementations of any of these
> >relationships. I really like Perl's current support for HAS-A: instance
> >variables. :^)
>
> Sure. But automatic delegation's faster than executing interpreter code to
> provide the same functionality, or it ought to be at least.
I don't think we can have automatic delegation, because the interesting
part of delegation is the deciding-when-and-what-to-delegate and deciding-
what-to-do-with-return-values part. If you think differently, I'd love to
hear your ideas for a Generic Delegation Model. In Class::Delegate, I had
come up with what I thought was a generic implementation (influenced heavily
by NeXTstep's AppKit), but then I saw Damian's Class::Delegation talk at TPC.
> I'm not soliciting a comprehensive solution, nor even really a
> perl-specific one, but more a general "Most HAS-A situations need X, Y, and
> Z" sort of thing.
HAS-A situations need pointers/references, probably the ability to
twiddle the insides of the objects they HAS, and maybe two-way pointers
that connect the HAS and IS-HAD objects. I think that's it.
It's not clear to me whether you're asking about HAS-A relationships
in general, or delegation relationships in particular, but I've already
said my piece on delegation. As to the other HAS-A relationships I'd
listed above, I think they're even less amenable to canonization than
delegation relationships.
- Kurt
