On Monday 15 December 2003 18:38, Leo Sutic wrote: > > From: Niclas Hedhman [mailto:[EMAIL PROTECTED] > > > > Back to the bottom-line; What about > > ServiceManager.release()?? Should it be > > deprecated? > > IMHO, > > 1. Deprecated, or > > 2. Enforced, or "soft enforced" (i.e. reported as a problem). > > > > I don't really care which one, but having a weak contract is not good.
> (I have seen this bottom line before.) :o) > basically, we've been here before. The sequence is usually that someone > introduces the concept of no release. Then someone else pops up with > a use case that *requires* a release. Then we get a marker interface > or extension like ReleaseRequirement. My "ReleaseRequirement" interface was not intended as part of the Framework/Container, but only each service API that requires it. > The only way out is to do a huge backwards-incompatible change: No > relase() at all. All components are singletons. > If you want something else, you have > to code it yourself. Singletons is a strong word, isn't it?? "Normal Java objects" - isn't that more natural. If the component requires releases (such as FileInputStream) it would expose a "close(), release()" or whatever... No? Regarding "back-incompatible"... You don't have to remove it altogether, people would freak, but deprecated and say "Merlin/Fortress is ignoring this method." Anyway, I just "hate" weak contracts... No argument can change that. If I need to live with weak contracts to satisfy legacy, I'll live miserably for a while... :o) Cheers, Niclas P.S. I did not initiate the discussion of removing release(), just that Stephen has this fancy "auto reclamation" which I argued can not be dependent upon, but could help me to find user errors, and with that came "my own" ReleaseRequirement interface to deal with "my concerns in my domain". --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
