It has been three hours and not a single response to this message. Looks like no one is willing to get into yet another IDispose discussion :-).
Jesse, I just wish to point out that the role of the garbage collector is slightly different than what Dispose() is meant for. The GC manages managed resources only. Dispose is meant to dispose unmanaged resources (deterministically). As a matter of fact, if a class does not hold any unmanaged resources, then in general there is no need for the class to implement IDispose. If a class implements IDispose, it most likely is dealing with some unmanaged resource, and therefore may require programmatic disposal. About "it is impossible to know for sure when an object is no longer required," this is an age old issue not just relevant to .NET. If an object is being shared and the ownership is not clear, then you have to look at some other techniques such as reference counting. The risk of calling Close() was always there even in the pre-.NET age. My 2 pesos (less than 2 cents). Pradeep http://www.tapadiya.net/pradeep ----- Original Message ----- From: "Jesse Liberty" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 29, 2002 6:08 AM Subject: [ADVANCED-DOTNET] When to use IDispose > I'd like to open a discussion of when to use IDispose (a quick search of the > archives shows that this has not been discussed recently). > > It is my theory that this idiom will be vastly overused. > > I'll start by quoting Richter: "In general, I strongly discourage the use of > calling a Dispose or Close method...When application code calls Dispose or > Close it is effectively saying that it knows when the application no longer > has a need for the object. For many applications, it is impossible to know > for sure when an object is no longer required." (Richter, chapter 19, > Applied Microsoft .NET Framework Programming (Microsoft Press, 2002). > > It is his last sentence that I want to pick up on and discuss. I suspect > that > > (a) the ability of the GC to do the job is greatly underestimated and > (b) the need to use close is therefore greatly overestimated while > (c) the risk of calling Dispose is greatly underestimated > > It seems to me that if your object is (or might be) passed to ANY method > calling Close is very risky. You simply can't know if other objects have a > reference to it, and you certainly don't want to keep track. The only place > it does make sense to me to use this idiom is when > > a) the object is created in a very controlled situation (a single method) > and does not leave that method > b) the object contains a very limited resource > c) you know when you are done with the object > d) you are making a LOT of instances > > In any case, I write all this to spark conversation on this issue. > > Thanks. > ------------------------------- > Jesse Liberty, President > Liberty Associates, Inc. > .NET Programming and Training > http://www.LibertyAssociates.com > > > > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
