[Prev][Next][Index][Thread]
Re: MI: why?
Panu Viljamaa wrote:
/* snip */
> The point against MI of implementation in my view is that you end up
> inheriting things you don't need while at the same time making the system
> harder to reason about and prone to conflicts. Delegation is the way!
>
> - Panu
That is a comment about the implementation, not about the concept. Eiffel,
e.g., allows one to inherit exactly the pieces that one chooses. Of course,
underneath and hidden away all the code and variables needed to support the
original concept of the ancestors are included. In principle, though, a good
optimizing compiler could strip a lot of that garbage away. At least for
applications where it isn't used anywhere in the app. And if it is used,
perhaps it's just as well to have the types be "compatible", even at the cost
of some overhead.
To my eyes, the real problem is slightly different:
How does one express the ancestry of a rhombus, a square, a rectangle, a
rotatable rectangle, a round-cornered rectangle, and an equilateral
triangle. I've yet to see an inheritance diagram that made any sense. It
makes me wonder is something basic is wrong with the very concept of
inheritance. (And it doesn't seem to matter which language either. The
languages with fancy MI just come up with a different set of unreasonable
inheritance trees.)
Follow-Ups:
References: