cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: [RT] composition vs. inheritance in blocks
Date Tue, 29 Mar 2005 19:10:01 GMT
On Tue, 29 Mar 2005 11:22:35 -0500, Stefano Mazzocchi
<> wrote:

> 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 or
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, 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

View raw message