[Prev][Next][Index][Thread]
Re: MI: why?
James A. Robertson wrote in message <387F0C78.BCA580EE@home.com>...
>I would have to say I disagree. I understand the point about code
>duplication. But I think the complexity added by MI is more costly.
>With MI, you have to have conventions as to the order of inheritance in
>cases where the same method signature is inherited from two superclasses
>(or more). You also have to deal with the possibility of inheriting the
>same class more than once.
>
>It's not that such rules are impossible - it's that they add
>complexity. Additional complexity slows the developer down, and at
>least in my opinion, MI for Smalltalk would add cost rather than
>reducing it.
I'd like to add my experience "data-point" to this. Back when I used
C++ extensively, any non-trivial class library that used MI
(of implementation) extensively was invariably more difficult for me
to figure out than the SI ones. MI of interface (ala pure virtual base
classes) never caused this added complexity problem, but MI of
implementation invariably did. I eventually reached
the point where I advocated banning MI of implementation from all
our C++ projects, and only allowing MI of interface.
Of course, some of my co-workers agreed with this position, and
others thought I was nuts.
Eventually, I quit caring, though, and simply abandoned C++ entirely.
Nevin Pratt
Follow-Ups:
References: