On Mon, Aug 13, 2001 at 04:18:43PM -0400, Dan Sugalski wrote:
> Okay, here's a question for everyone.
>
> I'm currently designing the object-specific opcodes for the Parrot
> interpreter. Most of this is pretty straightforward (methods, attributes,
> and suchlike things) but at the moment I'm a bit stumped on the whole issue
> of HAS-A relationships. (Well, that and designing a way to handle
> delegation flexibly as everyone and their brother's got a different way of
> doing it, and some people have multiple ways...)
>
> More specifically, should the interpreter handle HAS-A things at all? And,
> if so, what sort of functionality should be built in, vs what should I
> expect languages to provide in layering functionality? (It also influences
> what the interpreter's objects are known to have--we need an array to stick
> the hasa things into, if nothing else)
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. 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. :^)
- Kurt
