<snip/>On Tue, 29 Mar 2005 11:22:35 -0500, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
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
