Isn;t this a question of separation of concerns? No really - I know your going to thing this is one of those auto response replies .. but shit .. this look like one way overloaded interface.Here's an example component to consider...
it's a contrived example to make it readable. The actual code I based it on is, I can assure you, beatifully decomposed.
This component.... * might not run in Merlin 3.3+?
Will run in Merlin 3.3 and 3.4 because it implements a null constructor therefor logic falls back to classics.
Well that's good news. Might want to make a testcase out of it to make sure it stays that way.
* is not "avalon-framework 4.2 compatible"
Is avalon 4.1 and 4.2 compatible because it declares a null constructor.
let me quote:
"A component may declare either a null constructor, or, a single constructor with any lifecycle artifact as a parameter argument where arguments may be in any combination or order. Recognized lifecycle artificats include Logger, Context, Parameters, ServiceManager, and/or Configuration. In addition, the Context object may be substituted with a custom context interface and implementation.
NOTE: A component implementation may not duplicate constructor injection of lifecycle artifacts with the equivalent lifecycle stage."
The example is a component with 2 constructors, which violates the spec ("either...or"). Worse, the example component "duplicate[s] constructor injection ... with the equivalent lifecycle stage", which further violates the spec.
Note that if your first statement is correct (merlin can run the component), merlin itself is in violation of the 4.2 specs. For good reason.
The good reasons:
1. improved compile time checking 2. reduced memory consumption 3. significant reduction of lines of code 4. elimination of potential errors by component authors related to sequential artifact delivery 5. reduced dependency on framework interfaces
those are Good Things. But you could get all that in a different manner without causing any of the issues like the example highlighted above.
I disagree.
You going to have to explain this one.
Actually, I think you're the one who should be doing some explaining. And some research. And some reading of testcases and old e-mails.
I did not say introduction of constructor injection is a bad idea. Remember how this started. I said:
> "A component may declare either a null constructor, or, a single > constructor with any lifecycle artifact as a parameter argument > where arguments may be in any combination or order." > > -1 (as in veto not vote) on that change in specification. Please roll > it back as soon as possible.
This does not say "-1 on the introduction of constructor injection in general". You can introduce constructor injection into an existing avalon-compatible container without breaking any existing components [1, 2], as I've already explained to you and others many times, and demonstrated. I am fine with doing that (I applaud that). What I don't like is you making my components specification-incompatible.
C'mon dude, you're not even sure what your spec says and your actual explanation of how things should work is consistent with my objections...how on earth can you justify releasing such a thing into the world?!?
- LSD
[1] - http://cvs.picocontainer.codehaus.org/java/type1/
[2] - http://cvs.sourceforge.net/viewcvs.py/jicarilla/jicarilla-sandbox/platform/?hideattic=0
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
