On Tue, 29 Mar 2005 11:22:35 -0500, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
<snip/> > > I don't like multiple inheritance and this is not just because I learned > OOP thru java, but because every single time I wish I had multiple > implementation inheritance in java I found a way to go around the > problem with single implementation inheritance that was more elegant. I learned most of my OO with Smalltalk, Java has always seemed like a big step backwards by comparison... > I would go a little further and say that I believe inheritance is useful > only when used as a 'cascading' mechanism, in any other sense is > harmful: composition should be used instead. > > Why so? > > It's extremely hard to design for inheritance, a lot easier to design > for composition. That's FUD: a graph is a graph is a graph. The only question is how to expose or hide child nodes. With composition there are no child nodes until you add them. With inheritance the visibility depends on the language and the implementor. > And performing composition thru multiple-inheritance is a really > terrible way to do it. Why? because you need to go very deep in > describing what behaviors get exposed and what are protected, otherwise > things get messy very fast. Also FUD, again it depends on the language and the implementor. > Also, multiple-inheritance stops further composition: you seem to > suggest that a block that inherit multiply is a 'leaf block', one that > is your own application and that will not be used by others. > > Well, one of the reasons for block design was to sparkle the creation of > reusable application components without people to think much about them: > multiple-inheritance yields horizontal behavior changes to the inherited > components, which means that if I have block A inherit block B and then > block C that wants to use A but was already using B, but A modified B's > behavior a little with the inheritance, you have a problem! Only if you design things to allow the problem in the first place. If I'm using both blocks to start with I can specify A.foo() or B.foo() and pick or choose which version I want. If I start out using only B and later add in A and find out I have a name space collision on foo() then I have an issue. That's where the real problem lies with Cocoon blocks: unless the references are resolved at startup then you have the _potential_ for obscure run time problems as blocks get resolved dynamically. Since you may not want to do startup resolution on the entire graph, I think the way for Cocoon to support multiple inheritance is for the default behaviour to be to hide all inherited capabilities and require explicit exposure or to always require complete paths to the function. IOW, in this example , the only way to see the A version of foo() would be an explicit reference to A.foo(), otherwise the reference would fall back to B. > I am strongly against multiple implementation inheritance for blocks, > because what you want to do, if you care about reusability, is really > multiple composition and that is achieved with being allowed to > implement multiple behavioral interfaces. Given that this is more-or-less completely new territory, the terms inheritance and composition seem to be getting in the way. The real issue is how does the block language expose features from each block. You're describing the language as implementing "multiple behavioral interfaces"; from my backgrounds POV the easiest way to do that is multiple inheritance. > If you *don't* care for reusability, then it's true that multiple > implementation inheritnace can serve as a cheaper form of composition. > > But if I had to pick between improving block reusability or ease of > composition, I would go with the first, hoping that tools/syntax-sugar > would help the second (as it happened with Java). Well, that's almost all that it is about in this case: pure syntax. If you think about what's going to have to happen under the covers the end result is the same either way: you need a language to describe which features are visible from one block to another. If there's a term that is an abstraction for both inheritance and composition then that's what you reallly want... -- Peter Hunsberger
