On 1/3/06, Upayavira <[EMAIL PROTECTED]> wrote: > Reinhard Poetz wrote: > > --- Carsten Ziegeler <[EMAIL PROTECTED]> schrieb: > >>Gianugo Rabellino wrote: > >> > >>Yeah, and I really don't understand this - I (and > >>others) propose small > >>but simple steps to a) improve using Cocoon and b) > >>provide a smooth > >>migration path.
> >>So I'm coming back to my idea, is anyone against > >>adding constructor > >>injection to ECM++ or at least make it pluggable so > >>I can add it for my > >>own projects? The change adds only a feature while > >>maintaining 100% > >>compatibility. > > > > Without having time to understand in depth what you > > guys are talking about, I'd say that we should not > > block any features that don't introduce any backwards > > incompatibilities. If people disagree here, I would be > > very intersted in their reasons ... > > > > So +1 for your enhancements Carsten! > > Even more - Gianugo makes some valid points about the future. However, > at this point, we cannot prove that his opinion is correct. So in my > view, we should be taking multiple paths until one shows up to be the > clear winner. It's not so easy. First let me state that I don't have any particular blocker if all we're talking about is adding constructor injection to ECM++: whatever goes in the direction of a lighter and less-Avalon-dependant Cocoon gets my applause. I do have issues, though, when mixing models. something we're very good at. Keeping both interface injection and constructor-injection (well, why not setter injection as well at this point, shouldn't be too hard and, hey, gives one more choice) and telling users to "take their pick" isn't going to work: adding features blindly not because of architectural/design issues but because it's tiresome to add 5 lines of code and - at the same time - not considering how users might be confused by the fact that we're still using Avalon but we're subverting its very principles is just not going to work. Careful also about taking multiple paths (and again, this isn't quite the case of this constructor-injection stuff which gets my +0 as in it's not my favourite solution but I'm fine with it): removing cruft later on is hard, and the situation we are in how should prove it: once you've baked a cake, there is no way to get your flour, butter and eggs back to bake another one. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
