Re: Maintain list of attached event handlers (.Net 1.1)
- From: Damien <Damien_The_Unbeliever@xxxxxxxxxxx>
- Date: Fri, 13 Jul 2007 00:10:54 -0700
On Jul 12, 6:48 pm, "Armin Zingler" <az.nos...@xxxxxxxxxx> wrote:
"Damien" <Damien_The_Unbelie...@xxxxxxxxxxx> schriebOkay. I was just trying to highlight the fact that what was once a
Hi Armin,
Sorry to *** in, possibly with more unwelcome advice.
Nah, no problem. :-) Advice is always welcome.
Have you
considered the fact that it used to be best practice to always free
memory as soon as possible, but that now under the GC, the freeing
of memory is done when it is required/when it is convenient.
I know this, but if you don't release references, the GC does not even has
the /chance/ to free memory. That's why it is common practice to release
references as soon as possible. Not in order to free memory immediatelly but
to make it possible. (But I don't go as far as some people that even set
/local/ variables to Nothing at the end of a procedure. That's too much for
me).
best practice of "release immediately" (with respect to freeing
memory) is now a) not followed, and b) because of the GC design, not
even possible - it's all entirely under the GCs control, and it
follows a different strategy.
I guess what Peter especially is trying to get you to focus on is the[...]
I'm afraid, there is nothing new I can add. Instead, I can offer a (IMO)
good comparison:
Imagine, you know 50 people. From time to time you lend things to them.
Every 12/31 you want all lended things back. You have two choices:
a) At 12/31, call all the people and tell everyone to give the things back.
This means, calling also those people that have already given everything
back. It doesn't hurt to call them, but I call it "illogical" (please
replace it by the word of your choice). The phone costs or the time that
it takes is not an issue, but simply doing it although it is not necessary
is IMO not acceptable.
b) Everyone who borrows anything is put on a list. As soon as it's given
back, he is removed from the list. At 12/31, only the people on the list are
called.
You won't be suprised that I favor b) even if I have to maintain a list. I
do this because I consider it the "cleaner" approach.
I guess you favor a) ? :-) I accept this opinion - I just don't want to be
handled like an idiot because mine is different.
fact that all strategies for release have attendent overheads. Have
you ever done any robust COM programming in a C derived language? It's
amazing how complex it is to just make sure your reference counting
code is correct, and handles the edge cases - and that was because the
COM model was based around the "release as soon as possible" approach.
I know you've stated you're not looking at this from a performance
perspective, but from a "clean code" perspective. In Peter's code, we
can see 1 operation, in 1 place, possibly with the comment "Some of
these may have already been removed", which goes through the whole
tree and removes all of the handlers. I can go and look at that one
chunk of code, and know that I am *sure* that all of the handlers are
being removed when the form closes.
Contrast this with your solution. I have to read this "same" chunk of
code, and see that it is removing only those handlers which haven't
been removed. But I then need to go and review each handler, and
verify that it is removing itself correctly. And I then need to
examine all of the list maintenance procedures, and ask myself
questions such as "is this list operation thread safe?", "Does it need
to be?". Only after I've done all of that would I be as confident that
your solution is removing all of the handlers.
And even if I had verified your solution, I'd probably still go back
to the final "chunk" which does the cleanup and remove the list
checks, and let it remove all of the handlers (again, adding the
comment if you so wish), because a) I know that the removal code is
cheeper to run than the list checkup code (okay, that is a performance
argument), BUT b) because I'm going to use a belt and braces approach.
Sorry - I don't know if you know or understand the phrase "belt and
braces". I don't know if there's a German equivalent. It refers to the
practice of ensuring something happens (in this case, your trousers
staying up) by the use of more than method (using a belt, and also
using braces).
This post turned a bit epic. Apologies.
Damien
.
- Follow-Ups:
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Armin Zingler
- Re: Maintain list of attached event handlers (.Net 1.1)
- References:
- Maintain list of attached event handlers (.Net 1.1)
- From: Armin Zingler
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Peter Duniho
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Armin Zingler
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Peter Duniho
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Armin Zingler
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Peter Duniho
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Armin Zingler
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Peter Duniho
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Armin Zingler
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Peter Duniho
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Armin Zingler
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Peter Duniho
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Armin Zingler
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: John Saunders [MVP]
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Armin Zingler
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Damien
- Re: Maintain list of attached event handlers (.Net 1.1)
- From: Armin Zingler
- Maintain list of attached event handlers (.Net 1.1)
- Prev by Date: Re: Running out of Sockets
- Next by Date: RE: Do Not Show Property?
- Previous by thread: Re: Maintain list of attached event handlers (.Net 1.1)
- Next by thread: Re: Maintain list of attached event handlers (.Net 1.1)
- Index(es):