Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>> 2. discussing the merits of thread safety in A5 when in fact
>> the framework does not concretely support this - kernals
>> and containers above framework do this but the assertion
>> is being made that this is a framework issue - it is in
>> terms of future development - but this is in terms of
>> delivering something concrete that does not exist in the
>> framework today
>>
>>
>
>What he is arguing is, I think, that the explicit removal of support
>for some things in the framework would have bad effects on containers
>and kernels.
>
>The contracts the ECM has with its components may not have a basis in
>the framework - for example, the Poolable interface is nowhere to be
>found in Avalon/Framework, and you can thus argue that ECM
>overpromised and that there is no need to honor that contract
>when discussing framework issues, but that contract, that promise
>of the ECM to pool components *can not* be kept if you remove
>release() from the framework.
>
>It is not the case that removal of release() only impacts framework.
>In fact, I think we have reached the conclusion that *no*
>*container-managed* pooling of components is possible without
>release().
>
>At the same time, this container-managed pooling is something that
>people have found very useful.
>
>So I do not think you can neatly classify things into framework and
>non-framework issues, without thinking about how the framework issues
>impact the non-framework issues.
>
>
Leo:
You have got the point of my concerns. But let me go a little step
further and say that we have come a long way in understanding what
aspects of the framework impact tools and applications above the
framework - and this is leading to better understanding of what changes
/evolution etc. is needed in the framework to reduce client code while
maintaining portability.
>I understand that you argue against the "ECM is the only true reference
>container" approach seen sometimes. But your argument is also
>against container-managed pooling.
>
Not at all. I would really like to see the pooling question resolved
(I'm not ignoring you last email to me on that point). For me the issue
are closely linked to the approaches the framework enables for fundimental
extension.
>And that means decreased usability.
>And I'm against that.
>
Me to.
>
>/LS
>
>I'm off for midsummer's now, so I might not be able to reply to anything
>until Saturday. The only thing that has to do with this discussion is
>that
>I might come in contact with pools of liquor and herring, and that
>too much of that will cause my heart to be stop()'ed, my body put
>in a container (coffin) and dispose()'d, all of this before I even
>considered myself start()'ed.
>
What, no release( leo )
LOL - wish I was doing the same thing!
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
