Re: Maintain list of attached event handlers (.Net 1.1)
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Wed, 11 Jul 2007 21:13:15 -0700
On Wed, 11 Jul 2007 19:25:10 -0700, Armin Zingler <az.nospam@xxxxxxxxxx> wrote:
I'm dwelling on it because you are again saying "it doesn't matter".
Completely wrong. It does matter a lot because it is the precondition for
the whole discussion.
It's not. It never was. Removing the event handlers in the middle has no bearing on what the most efficient way to clean up at the end is.
Glad to read this, though I'd call it logic not aesthetics.
To make a logical presentation, you have to base it on something. Logic does not exist by itself. It requires axioms and operators. You haven't stated any axioms yet, so you cannot claim that it's "logic".
My axiomatic goals are performance and memory usage. You seem to think those are not relevant, and I have said that's fine. However, you haven't stated any other axiomatic goals on which you claim to base your decisions. I'm left with aesthetics, simply because that's a viable goal in code design at least some of the time and I have not guessed any other axiomatic goals you might have.
If you would like to state explicitly the axiomatic goals that guide you design, please feel free to do so. Please do NOT feel free to claim that your design is "logical" if you have not yet stated what axiomatic goals are used as the starting point for that "logical" conclusion.
But it _does_ have to be done.
Yes, but not twice. It /has/ already been done. The code has alrady been
written in order to do it /before/.
"Before" what? "It" what? Your posts would make a lot more sense if you would be more explicit about your nouns, instead of using pronouns. When you use pronouns in such an isolated context, I have to make some assumptions as to what they mean. You haven't declared a noun in advance of the pronoun, and you are unhappy with the assumptions I am making about your intent. So stop forcing me to make assumptions.
You are ingoring the preconditions. I
explained why they are how they are. If you like to discuss under
different preconditions, do it with whomever because it won't help
/me/. A answer to a question that I did not ask, doesn't help.
This all started with a very general, vague question about your overall goal. The only two replies you received both said essentially the same thing. If you wanted an answer to a different question, you should have been more clear about that.
[...]The complicated implementation "does not have to be done" any more
than removing non-existent handlers "does not have to be done". So,
how is it that you feel aesthetically it makes more sense to choose
doing the thing that doesn't have to be done that is more
complicated, than to choose the thing that doesn't have to be done
that is simpler?
I'm afraid, I don't understand this sentence.
Which sentence don't you understand? Out of the three that you quoted, that is.
The whole situation can be expressed VB-ish: (no, not executable...)
If immediatelly remove handlers? then 'programmer's decision
This is fine. It doesn't affect the rest of the discussion.
immediatelly remove handlers
Fine.
if do more than necessary? then 'programmer's decision
You will have to define "do more than necessary". By any obvious interpretation of the phrase, your conclusion does not result in not doing more than necessary.
do more than necessary 'means: detach some handlers a second
'time when closing the form
'(aka illogical)
The cost of detaching some handlers a second time when closing the form is LOWER than the following clause:
else
maintain a list of remaining handlers
THIS is expensive. To maintain the list of remaining handlers is "more" than to unsubscribe some handlers that have already been unsubscribed. You cannot claim that you are doing "more than necessary" by unsubscribing some handlers that have already been subscribed while at the same time ignoring that you are doing "more than necessary" by maintaining a list of remaining handlers.
do only what's necessary 'means: only detach remaining handlers
'when closing the form (aka logical)
Can you not see, in your own way of presenting the situation, that in the supposed "do more than necessary" clause, you have only one action, while in the supposed "not do more than necessary" clause, you have two? How is doing one thing "more" than doing two things?
end if
else
'...
end if
- You are still trying to write the lower Else part, but the first
If-expression has already been evaluated True. That's the precondition.
No, I am not "still trying to write the lower Else part. I am trying to explain to you that it does not matter what the first "if" condition is. The "do the least necessary" answer is still to simply traverse the entire data structure when the form closes.
The corresponding Else part is completely out of interest. Feel free to
discuss it with somebody else but it's not what I am interested in.
Nor am I. In nearly every post, I explain to you that it's irrelevant, and yet in every reply you come back and tell me that you think I'm still talking about it. How many times do I have to tell you I'm not talking about that before you figure out that I'm not talking about that?
- At the second If, you decide for True because you want to avoid the
"maintain a list..." job, whereas I decide for the else block. I do accept
the additional programming work ("maintain...") in order to "do only what's
necessary", whereas you don't.
I'm not talking about additional programming work. I'm talking about code execution work. That said, you have MORE of BOTH. In what way is that not "doing more than is necessary"?
Our different decisions at the 2nd "If" are caused by differently weighting
the pros and cons.
Only if by "differently weighting the pros and cons" you mean "Armin is completely ignoring the cost of maintaining the list of not-yet-removed handlers".
You claim the decision is about "not doing more than is necessary", and yet your solution is definitely to do more than is necessary.
Now, if you have some other criteria than how much you are "doing", that's a different matter. But you have to state that criteria for me to comprehend it. So far, all you are writing is "doing more than necessary", and the way I interpret that is that you are talking either about the work in programming, the work of the code executing, or both. From what you've written, I have narrowed that down to "the work of the code executing", but even by that criteria, your conclusion is wrong.
For me, the True block is almost unacceptable whereas you
accept it.
But you have not stated a logically correct reason for it to be that "the True block is almost unacceptable".
To me it is almost unimportant how much work it takes to avoid an
almost unacceptable situation. The additional reason to choose the Else
block was pure technical interest in whether and how it is possible.
Meanwhile I know that it is not possible the way I was looking for,
nevertheless it is possible. Therefore I do it. If it wasn't possible at
all, I would have to swallow the bitter pill and choose the True block.
Why is writing less code, and executing less code, a "bitter pill"? For most people, that's a win-win situation. For some reason, you are completely against it. You spend less time working on the code, it's simpler and so less likely to have bugs, and it takes less time to run. What's so "bitter" about that?
So, we won't find an agreement because we have different weightings.
No problem. I will repeat my arguments until you got them and see that
your's are illogical.
You have less of an understanding of "logic" than you appear to think you have.
I thought we are grown up enough to avoid this endless
loop. Obviously you are not. Anyways, I won't have to add anything new.
You already did. I've replied to it (see above).
Pete
.
- 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: Peter Duniho
- 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: Maintain list of attached event handlers (.Net 1.1)
- Next by Date: RE: System.Diagnostics.StackTrace future ?
- 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):
Loading