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.

Reply via email to