NoTrackingReleasePolicy obsolete?

[hammett]

'Castle.MicroKernel.Releasers.NoTrackingReleasePolicy' is obsolete:
'This class is a hack, will be removed in the future release and
should be avoided. Please implement proper lifecycle management
instead.'

What is "proper lifecycle management"? I dont care for disposable, and
I want the container to not care as well.

--
Cheers,
hammett
http://www.d-collab.com/
http://hammett.castleproject.org/

[Krzysztof Koźmic]

If you don't want to dispose your class why make it disposable?

Krzysztof Kozmic
sent from my phone

--
You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-d...@googlegroups.com.
To post to this group, send email to castle-pro...@googlegroups.com.
Visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[hammett]

Who said I do? Types that I don't own may do it - see mvc's controller for example

Sent from my iPad

[Kelly Leahy]

Yeah, or what about frameworks like caliburnmicro that don't have any good way to even do a 'release' on your components?  It would be nice if there was a way to tell the container in a more clean way that it should never track non-singleton instances - ever (for people like us that want it).

[Krzysztof Kozmic]

This aside, what's the downside of properly disposing them?

More straight to the point as to why this type is now obsolete - I have seen it used multiple times and every single time where it was used, it lead to more problems than it worked around.

Obsoleting it is a way of making people work harder if they want to shoot themselves in the foot.

Most of the time people use it because they don't really understand what problem the release policy solves in the first place.

So the goal is to, push people towards fixing the underlying problems they've got with their lifecycle. And if they still want to use NTRP, they can (and writing one after/if the built-in one is removed is only a few LOC).

-- 

Krzysztof Kozmic

[hammett]

It took me some time to realize that we shouldnt demand nor expect
that people become experts in every tool they use. That was something
I had to repeat on a daily basis when working for MS...

Code that we write is not the end but the means to achieve something.
This *something* is valuable to end-users of some sort. Tools like
Windsor, MR, NHibernate/etc should help the dev to get there faster.
The dev main focus is -- rightly so -- on what she's building, not on
the toolset.

With this principle in mind, saying that people should use this or
that in the *right way* -- not even going to the to the merits that
*right* vary by person -- is wrong in so many levels.

[Krzysztof Kozmic]

The goal of Obsolete message is to make people stop and acknowledge it's NOT a solution, it's swapping the problem the have with a different problem.

The *right* way, as you say, is different for every scenario.

What do you suggest we do instead, put a link to doco page about lifecycle in the message?

-- 

Krzysztof Kozmic

[hammett]

It's a perfect solution for me, actually, and I think I know what I'm doing. So please don't let your strong opinions manifest in these API decisions..

Peace

Sent from my iPad

[Kelly Leahy]

I personally think that Disposal tracking is not something I'd expect my container to do, and don't see why this isn't an opt-in facility like StartableFacility or something else (i.e. a facility that supports disposal tracking on top of the normal IoC container behavior).

 

I think the number of people that are surprised when their site crashes because they forgot to Release their MVC controllers in the controller resolver, or because they don't use Release with all their Resolves indicates that the majority is probably in agreement (that they don't expect Disposal tracking to be a feature of the container, and specifically that they don't expect the container to hold on to references to their transient objects).

 

The more we use things like UI frameworks that are container aware, the more this becomes a problem, as most of these frameworks that I've seen don't support releasing of objects when they are done (without you doing something strange like making your View's destructor call into your container to Release your view models, etc.).  This leads to many applications that have "memory leaks" due to the fact that the container holds on to transient references - I'd bet the number of these applications where those transient references are actually IDisposable (the whole reason for tracking the references) is nearly zero.

 

I've actually written a lot of application logic that uses IDisposable objects because I have several applications that make heavy use of Windsor and also do lots of File I/O.  However, even in those cases, I found it intuitive to just use using blocks, and I never agreed with the opinion that IDisposable was an "ancillary" requirement of the implementation class - in all of those cases, we defined the implementing interface to be IDisposable-derived and to us it always made sense to do so (and would have even if the container were not involved).

 

Anyway, I'm with Hammett on this one, even if it's not for the same reasons he has his opinion.

 

You wouldn't believe how many applications that use Castle.Windsor with Caliburn.Micro and have massive memory leaks because they don't properly release objects resolved from the container.  I'm sure most of the people doing this don't believe it either!

 

Kelly