Niclas Hedhman wrote:
Berin Loritsch wrote:
Niclas Hedhman wrote:
2. Timing. I am not comfortable of making a release of Avalon 5, Avalon Planet, without being able to deliver. We need ramp-up period, and it will take a fair amount of time.
Avalon 4.5? Big enough jump to get the message accross, yet not fully 5.0 to let you mature.
4.5 = 'allowance for component authors to use constructor injection of life cycle artifacts, that other AF4 containers are not interested in supporting'
4.5 = Current Avalon Planet concept--something that is beyond the scope of Avalon Framework alone.
Is that what you really mean?
If you oppose the constructor injection of life cycle artifacts, then spell it out, instead of all the mumbo-jumbo about how to solve a situation that has been created without looking at the issue.
That particular point isn't the issue, but how that decision process was made--without the input of others who depend on framework. The clean
break allows whatever changes to the contracts are needed to make "Avalon Planet" a reality while at the same time providing a known set of contracts for the Excalibur code base. It's bad enough we have to maintain compatibility for people who have investments in the Excalibur containers--when fundamental contracts change underneath us at the same time it begs the question "what's next"? And is the next thing going to be as easy to implement? These are questions no one can authoritatively answer because we aren't there yet.
I am left with the impression of building on sand, and that is not a solid foundation for any structure. You guys want the freedom to do what you need without shackles--I trust you to maintain as much compatibility as you possibly can--but at the same time we need something that isn't going to change unpredictably. Unpredictable means without our input (almost has the same taste as taxation without representation).
It is not necessary, to jump to other conclusions that requires a fork. If you are really opposing the 'enhancement' for the component author, bring forward the reasons why this is such a bad thing.
1. I think it is great as component author to throw in the artifacts into the constructor.
I agree. the one item isn't the major issue--it is how the change happened and is managed.
2. I think (but not sure) that it can't be very hard for a container to support it.
I dunno. Are we talking full Pico style constructor injection or more simple Avalon artifacts in the constructor? What happens when there is a no argument constructor AND a constructor that accepts arguments--and they are both public?
These are important details. Full Pico style constructor injection is more involved to support within the current framework for either Fortress or ECM. It would be easier with Fortress--but still a lot more work than we would like to be surprised with.
So, again; Where is the problem with 4.2 ??
Why not have an Avalon Planet version out there--you can even call it 4.2 if it makes you feel any better. But that aside, a very real issue is that Avalon Framework is a product that several projects rely on. It really needs to be supported as a product until there is such a thing as Avalon Planet.
--
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
