Not expert myself, but:
The way I understand it is that not all objects are transient from the
perspective of the kernel -- we have custom lifestyles and that means
that the kernel is responsible for tracking the life of instances.
If it were not, consider the case:
[PerWebRequest]
class A
c'tor(B b) {..}
[Transient]
class B : IDisposable
**
k.Resolve<A>()
... work ...
**
If the reference to (:A) was dropped, how would the lifestyle manager
dispose it at the end of the web request? And since you don't
instantiate B yourself, then B would also never be disposed.
Perform these thought experiments yourself with a few of the different
lifestyles you have available to you:
* Per Web Request
* Transient
* Pooled
* Singleton
* Per User Session
* Per Transaction
* Per WCF Operation
Fairly soon you will realize that if the kernel is not tracking the
dependencies it instantiates you are going to leak, but in another
way.
This is actually exactly what you'd do in C++:
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
Consider what you would have to do there to track objects.
Yes, you can make everything singleton like is the default and then
never release them - fine - but the moment you start to go outside of
that tiny box you need burden.
Cheers,
Henrik
On May 26, 3:27 pm, mynkow <[email protected]> wrote:
> true...
>
> but if I have to release those objects manually why we should have GC?
>
> PS: I know that the functions of GC are more complicated and how it
> works....
--
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en.
