On Tuesday 26 November 2002 19:10, Stefano Mazzocchi wrote: > Mircea Toma wrote: > >>Stepanossov, Kirill wrote: > >>>Committers, if this accepted, could you still leave different "toolkits" > > > > for > > > >>>building customized containers available ? > >> > >>Why does everybody here think that COP and inheritance don't mix? > > > > They can mix but not very elegantly. > > that's not my perception. > > COP is promoting Composition as the > > > main design pattern isn't it? > > Sure, but nowhere is stated that these components can't follow OOP > patterns themselves.
No, nowhere. Is just akward that's all. And that's not a good sign you know that. As Stephen said OOP is complementary to COP (or orthogonal?!). > >>Example: Cocoon will need the embeddable container to implement cocoon > >>blocks, but cocoon blocks will have features that are cocoon-specific, > >>so Cocoon will have to "extend" this container to fit its needs. > > > > If you think about blocks in the same way Cocoon extends ECM to provide > > the specific functionality then you have a clear case were inheritance is > > not doing a very good job..... > > Look: cocoon needs user-level application modules. think of them as COP > for webapps. No web technology allows that. Ok. > > Now, either we write our own container or we work with the avalon > community to have the functionality we need in place. But *much* of this > functional requirements will be cocoon-specific (like a sitemap exposure). What's wrong in using Avalon as a container for components that put together will create a container for the cocoon-specific components. I guess that's why Avalon was called a "server of servers". > So, tell me, how would you suggest we move on? Agressive ... ? Remember you're the one trying to bring peace and order here! > write *yet another > container* because the COP patterns suggest that and we don't want to > *pollute* other containers with cocoon-specific stuff? No, I'm suggesting that any feature that is not general enough to go into Avalon is to be modeled as a component/service deployed on top of it. Even if the service would be another container. > why can't we take what's there and *extend* it for our needs? what's > wrong with that? Tell me, in Java every time you need new functionality you go to Sun and ask for another compiler reserved word or you'll create a object/method that will give you what you need? Mircea -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
