JC> Most who'd seriously question that don't really know what they're
 JC> talking about.  I think Booch said it well: MI is a bit like a
 JC> parachute.  You don't need it very often, but when 
 JC> you do need it, you REALLY need it.
I'd have to agree here.
 PP> I have yet to see a case where I'd *REALLY* need it.
I've seen *one* case where I needed it.  And I defied my project leader (who 
was almost paranoid about MI) to find an elegant non-MI solution.  He 
couldn't...
I was working with a pre-built device driver kit for the MMI product we 
worked with.  The DDK was class-based (I think that if I were to do it again, 
it would be template-based, but that's another story).  The actual device 
driving was done in an IO class, the scheduling of requests was done in a 
scheduler class, etc.  In order to get specific behaviour (i.e., address 
parsing, etc., as appropriate for the device, which was a member of 
scheduling, and i/o done in the right way, whether the packet was for serial 
transmission or proprietary card), you simply derived your behaviour class 
from the base class, and overrode the right virtual (and pure virtual) 
functions.
The problem arose when I needed to support multiple schedulers and multiple 
i/o types... in order for the scheduler to call the i/o module to get 
information on the current i/o type and capabilities, all i/o's had to be 
derived from some MyIO class - I could cast my IO* to MyIO* (using 
dynamic_cast(), of course) and call the functions that way.  So why 
not have MyIO derive from the BaseIO?  The problem here was that different IO 
objects derived from different bases.  They had a common ancestor from the 
DDK, but there were other IO classes (SerialIO, AsyncIO, AsyncSerialIO) that 
they derived from... These were classes that were part of the DDK so I 
couldn't change them.  And MyIO couldn't derive "selectively" from these (I 
could have used templates, but then I wouldn't have been able to do the 
dynamic_cast since I wouldn't know whether it was MyIO, 
MyIO, or MyIO!), so MI was the only choice left.
Rewriting the DDK for a single driver was never an option...
 PP> I think of it as the GOTO of object-oriented 
 PP> programming and makes me puke just like the original 
 PP> GOTO... ;-)
Like any other tool of the language, goto's are a required part, but overuse 
is a bad thing.  Whether it is goto, MI, realloc, or whatever, they have 
their places - just usually in as few places as possible.  A good programmer 
never closes his/her mind to these tools, but realizes that these tools are 
generally the sign that a better design is in order (if possible).  If that's 
not possible, s/he will use the tool, period.
 PP> ... There are two major products to come out of Berkeley: Unix and LSD.
And most people would say this is NOT a coincidence.  :-}
--- Maximus/2 3.01
---------------