cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] composition vs. inheritance in blocks
Date Tue, 29 Mar 2005 21:27:30 GMT
Peter Hunsberger wrote:
> On Tue, 29 Mar 2005 11:22:35 -0500, Stefano Mazzocchi
> <stefano@apache.org> wrote:
<snip/>
> 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.

Exactly, we could have internal and external sections of the component 
declaration in sitemap in the same way as we allready has internal and 
external pipelines. For pipelines I suggested earlier that inhertiance 
is done through a special map:mount, in that way one is explicit about 
search order and where in the uri space the blocks sitemap is mounted. 
Also I proposed that we have a special protocol for polymorphic access 
for avoiding supprises.

We could have similar constructions for component inheritance. I.e. all 
or individual components from an extended block can be added to the 
component section in an extending block, if there are several components 
with the same name in the components section, the order is significant. 
One have to explicitly ask for poymorphic behaviour for component lookup.

<snip/>

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

Agree, what we need to discuss is what access patterns we want to 
support between two blocks for different service types (pipelines, 
components, flow?). I guess we all agree about that a "use" access 
pattern with possibility for having internal services is needed. IMO we 
also need a polymorpic "extend" access pattern for supporting the 
"extend and overide default behaviour" style of webapp composition.

> The real
> issue is how does the block language expose features from each block.

As described above IMO this could be done on a more detailed level with 
mounts in the sitemap for exposing pipeline services and though the 
component section for exposing components.

Thinking further about it I'm quite sceptic about declaring "implements" 
and "extends" at the block level, it should be enough to declare what 
blocks it is dependent on. The exact nature of the dependence can better 
be described in the sitemap.

Of course I think that it would be cool to be able to say that a block 
depends on a number of interafaces and to be able to supply it with any 
other set of blocks that implements the interfaces. But as long as no 
one have made any concrete proposals about how to declare the behaviours 
that a certain interface contains, I wonder if it not is asking for 
trouble and all kinds of runtime errors by having "interfaces" without 
any possibillities to check the contracts.

<snip/>

/Daniel

Mime
View raw message