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

[Daniel Weinreb <address@hidden>]

Anton van Straaten wrote:

>Daniel Weinreb wrote:
>
>>In none of these cases did the need for multiple inheritance come up.
>>We worked on this product for several years and just didn't need
>>multiple inheritance anywhere.
>>
>
>Do I understand correctly that you mean one or both of the following:
>
>* Many (or all) of your classes implemented only one Java interface
>
Well, I didn't actually say anything about that one way or the other, 
but now that you ask,
let's see: I think that's true.

>
>* Classes that implemented more than one Java interface were always able to
>inherit the implementation for those multiple interfaces from a common base
>class, thus avoiding the need to duplicate interface implementations.
>
Um, often there wasn't any implementation to inherit, because the some 
interfaces were pretty simple,
having few methods, and the implementations of those methods didn't need 
to do any sharing that
requiring inheritance (only sharing that requires subroutines).

>
>
>What I'm saying is that either of the above constitute a limitation in
>design 
>

Wait, wait, wait.  What do you mean, a limitation in design?  We didn't 
set any limits on design.
The design wasn't built around any language limitations.  We just 
designed it the way that seemed
natural and proper based on what we were trying to do.

>that can, in some cases at least (I'd argue many cases), lead to
>designs that aren't as well factored as they could be.  In essence, the
>above implies that the constraints of implementation inheritance is
>affecting the architecture of your interfaces.  But it is to avoid exactly
>this that we want to separate interfaces from implementations in the first
>place.
>
Nope, everything was factored the Right Way.

There could have been circumstances in which proper factoring might have 
called for multiple
inheritance, and then we'd have had to think about what to do.  In some 
cases, we could have
dealt with it via delegation, c.f. The Treaty of Orlando.  But mainly it 
just didn't come up.

>
>
>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?

> that it's always possible to fit a design into a
>single-implementation-inheritance approach, without having to duplicate any
>implementations.  I agree it's possible - I did that kind of thing for many
>years myself.  However, the fact that it's possible to avoid this issue
>doesn't mean that avoiding it produces the best designs.
>
We didn't consciously "avoid" anything.

>
>
>I'm suggesting that (a) the ability to decouple interfaces from
>implementation, combined with (b) the ability to implement multiple distinct
>interfaces on a class, provides factoring opportunities that don't exist
>when you treat each class as essentially having a single interface. 
>
I'm certainly not advocating treating each class as essentially having a 
single interface.  Multiple
inheritance of interfaces is very important for many real-world jobs. 
 Our software system did
use multiple inheritance of interfaces, which Java wisely supports.

>  I think Java's single-implementation-inheritance
>combined with a complementary, secondary reuse mechanism of some kind might
>work quite well, and enable a kind of design that perhaps isn't being fully
>exploited currently, for practical reasons.
>
Yes, I agree.

>
>
>To put it much more broadly, the ability to reuse code in powerful but
>manageable ways is a very mundane requirement with quite large practical
>implications.  I don't think existing languages have really fully explored
>the possibilities, and I'm quite convinced that Java hasn't.
>
>Anton
>

Sure, I agree completely.  There are some jobs for which things like 
mixins are the answer. I just
didn't run into those in the BPM (a.k.a. B2BIS).  And furthermore there 
are even things that
Flavors and CLOS are not powerful enough to do (c.f. that Zippel and 
Hoffman stuff that I
referred to in earlier mail).  There's no one boundary; it's a whole 
landscape of possibilities,
starting mundane and getting more and more powerful and sophisticated 
and exotic.

>