Daniel Fagerstrom wrote:
damn, hit sent too early.
>> If you *don't* care for reusability, then it's true that multiple
>> implementation inheritnace can serve as a cheaper form of composition.
>
> For the majority of Cocoon users I would assume that blocks that are
> possible to extend and override is easier to reuse (considered that they
> have a good design of course), than just a lump of components and
> stylesheets.
what the hell are you talking about? the problem on the table is
multiple inheritance, not how granular the services the blocks offer are.
There is *NOTHING* that indicates that if you had MI or not the blocks
will be more or less granular.
>> 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).
>
> It's not either or. It's not exactly rocket science to build a mechanism
> for mutiple inheritance so we can have booth.
> We just need to discuss what we want to achieve and how to achive it to
> get it right.
I consider multiple inheritance for blocks FS: YAGNI!
Show me *one* example where single inheritance and multiple interface
composition can't echieve what you want to achieve and I'll change my
mind, but until then I'm stongly -1 on MI for blocks.
--
Stefano.
|