Yes, I basically agree with you. The only thing I would question is your comment from another post:
> have a reference to this object that > contains unmanaged resources, and you absolutely > need to know it has been released, the IDispose > pattern is a good way to handle it. My point (and > Richter's if I read him correctly) is that such a > situation is very rare. I'm not sure I agree with "very rare". Almost all of the code I write either involves using GDI+ resources or database connections. So I use this all the time. If by "very rare" you mean that there aren't many different kinds of situation where this is useful then I agree. But to me "very rare" implies that I won't run into situations where this is appropriate very often, and that I would disagree with. Admittedly this is splitting hairs... I would say that it is useful in a very small number of scenarios, but two of those scenarios happen to crop up all the time. -- Ian Griffiths DevelopMentor ----- Original Message ----- From: "Jesse Liberty" <[EMAIL PROTECTED]> > Great, then we are on the same page, just arguing about emphasis. The > problem is, I don't think this idiom and its dangers are well understood, or > even well documented. > > > > > 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 > > > > Yes. So GDI+ resources and DB connections would seem to meet these. You > > usually obtain and then release these in a single method, they are usually > > expensive, and you do make an awful lot of them. (At least one every time > > your app has to paint itself or your web app needs to show a page.) > > > > > > As for its utility elsewhere... Well I've not used it for much > > else, I have to admit. But I use it an awful lot in the two > > scenarios I describe. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.