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
|