RE: Java interface natural history was RE: "static" declaration

[address@hidden]

> >
> > Wait, wait, wait.  What do you mean, a limitation in design?  We didn't
> > set any limits on design.
> 
> Perhaps not in that system.  But the issues I'm referring to can constrain
> designs in many systems.
> 
> Certainly, many programs don't require the capabilities I'm talking about,
> and many others that do can nevertheless get away without them.  But I think
> there's a danger here, based on the way that languages tend to limit
> thought.  Something that's factored the Right Way for a language with single
> implementation inheritance, and no explicit support for multiple interfaces,
> might benefit enough from refactoring into a multiple interface design 

Whoa, I'm confused.  You seem to be contrasting
"language with single implementation inheritance'
against "multiple interface design".  But multiple
interfaces is multiple interface inheritance, not
multiple implementation inheritance.  Anyway I'm
not sure why we're talking about "no explicit support
for multiple interfaces" since I think we both agree
that multiple interfaces is very important.


> > >It sounds as though you may be claiming that good designs don't
> > >need to run into this issue,
> >
> > Certainly they don't.  Suppose you are tasked with writing a subroutines
> > that takes the square root of a floating point number.  Well, I bet it
> > doesn't need to run into the issue of multiple inheritance, right?
> 
> I have two responses to this.  First, of course, I'm not claiming that all
> systems need multiple interface or implementation inheritance down to the
> most granular level, necessarily (although I could easily be convinced to
> stretch that far, see below).  I'm talking about the kinds of systems I've
> run into in real life, though.  There are plenty of simple systems out there
> for which a PHP web page is a perfectly practical solution - I'm not talking
> about those cases.

I spent the last three years working on the eXcelon
Business Process Manager (BPM).  We designed and
implemented version 1, and then redesigned it
and reimplemented it from scratch to make version 2,
based on our experience with version 1.  This effort
involved four top-grade hackers plus about five
more junior hackers, over the course of three years,
so we are not talking about a small system.  But
the need for multiple inheritance of implementation
just did not arise.  There are probably  a few places
where we could have made use of some more sophisticated
language features that Java doesn't have, but really,
these were very minor thorns in our side compared to
the issues that really took up our time.


> 
> My second response is that in fact, the task you've set might well run into
> a requirement for multiple interfaces,

We did use multiple interfaces and inheritance of
interfaces; we didn't use multiple inheritance of
implementation.


> In designing, decomposing things to the max is almost never a bad thing - at
> least identify distinctions between entities, even if you can't or don't
> implement those distinctions explicitly.  But when languages don't allow a
> certain type of distinction to be made, it can have negative effects, on
> programs, designs, and the thinking of designers and programmers.

Yes, I agree with that, but I'm not sure it's in
conflict with anything I am asserting.  Umm, this
conversation may be getting too complicated for email...

-- Dan