I'm not really following the short term comment - if there is a short term solution it implies that there is a long ter solution which in my understanding has not been presented. If I look at Excalibur event mpool I have some contracts which after refactoring relative to the meta package could become part of the framework lifecycle model - and as such, influsnece lifestyle decisions concering component recycling. If I look at the Turbine Fulcrum package there is an equivalent set of of interfaces (pools, recycling, etc.). At the same time I wondering to myself if we are simply overloading lookup with too many semantics? What if you have an A5 interface that seperated pooled and non-pooled obect lookup? I.e. explicit understanding that transiwent object dependencies are not the same as singleton dependecies. I don;t the answer just yet - but from a purist architectural point of view - something smells wrong in the corner of the world.
My particular solution would be the introduction of the Resettable or equivalent interface. You seemed to be hinting at something alot more complex. So, I was leaving the door open for you to expound on it. ;P
As to A5 lookup semantics--I would prefer something much simpler. I like having one interface for everything. You shouldn't have to know what is going on.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
