David L. Nicol wrote:
>
> > The other standard solution is to
> > add a "Person has-a Employment_Status" relationship,
> > but that doesn't feel much better.
>
> It feels fine to me. Person has-a gender, person has-a job,
> it's more politically correct, even, than pigeonholing. You
> can even do dynamic multiple dispatch based on your has-a list,
> whatever it looks like.
When I started this thread, I knew everyone would tell me that
delegation is the answer: I included the note that I knew about
that, but I guess the bias against MI is just too strong.
My point was that, given that I want MI, that there is a simple
modification the the language (though maybe not its implementation)
that would save some programming effort. And I strive to be Lazy!
When you tell me how simple delegation is, you are considering
only the relationship itself. If I really want IS-A, and am forced
to use HAS-A, then the mismatch results in added complexity
(though not as much as when you use IS-A when you should use HAS-A)
Consider, for example, the implementation of the C<isa> method (in
UNIVERSAL). Its easy to provide the additional predicate methods,
but even easier not to have to. Then consider object creation
and destruction. Even in Perl I need destructors because I usually
implement a package-scope C<find> method for each class. Again,
its not difficult to implement the house-keeping, but its easier
not to have to.
> In my opinion, as long as we're checking object class with
> programmer code instead of automatic polymorphism, it
> doesn't make any difference.
Checking an object's type is, in most cases, a seed around which
complexity grows. Possibly more evil than C<goto>, definitely
more evil than C<if>, it is to be avoided in any non-trivial,
high-level, code. (yes, I too am biased :)
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.
