Re: Consuming your own events.

<quote>
http://msdn2.microsoft.com/en-us/library/wkzf914z.aspx seems pretty clear
to me.</quote>

oddly I do not think I had ever seen that exact page until now, but it is
clear even in the 1.1 version that you must call the base implementation of
OnXXX.  But I did condition myself to always call base after a discussion
about VB.Net's ability to alter c#'s default IL callvirt (I can't remember
the keyword off the top of my head, I think it was something like MyClass)
and about it being unclear to inheritors what will be called and therefore
bad.
I don't find it surprising that the docs are so explicit on having to call
your base implementation though or that it is causing a great amount of
discussion, (at least some of) as the architects involved clearly felt that
virtual methods need to be treated with a degree of respect. Anders
Heljsberg did an interesting interview [1] in which he explained that vitual
methods are call back hooks to be wary of and added this afterwards.  I know
it's about the language c#, but I think it is still valid for consideration
regarding frameworks anyway.
<interview quote>

*Bill Venners*: It sounds like your not as concerned that the person
overriding the method won't correctly implement the promises you've made to
the caller. You are worried about all the promises you have to make to the
person overriding the method.

*Anders Hejlsberg*: I'm concerned with both, actually. Virtual has two sides
to it: the incoming and the outgoing. People are very good about thinking
about what the contract is on the incoming. They are very bad about thinking
about the outgoing contract.
</interview quote>

<quote>
If they're doing a lot of
Form programming and must deal with the OnXXX pattern, a RaiseXXX pattern
could be viewed as just adding friction.
</quote>

Adding friction should (IMHO) generally considered bad for a framework,
especially the .Net standard framework, as you have no idea what all your
consumers will be trying to do.  I suspect that the OnXXX  approach was
taken on balance a) to reduce friction; b) keep perfomance good for derived
classes and memory constrained frameworks (compact) / platforms where
garbage collection is a bit different (xbox) (a delegate for an event is,
afterall, yet another object; and that the back hook is clearly documented
under development fundamentals.
Is it correct? I don't know for sure, but it is fairly clear to me how to
use it.  It would be nice to have some code analysis tool (hint: come on
fxcop!) to help enforce calling base as standard.  I would certainly ask why
the base implementation is not being called in a code review.

I know I would be worried if the dev's I worked with didn't know how
important it is to call the base class implementation of an overridden
method by default.  But I am frequently reminded that it has to work for the
lowest common denominator, no matter how much we may dislike that fact.  No
offence was intended by that, if you are writing a framework then you have
no idea who will be hired to use it later.

hopefully all of that came across as I meant it,

Just my thoughts,

James

[1] http://www.artima.com/intv/nonvirtual.html

On Jan 31, 2008 5:44 PM, Peter Ritchie <
[email protected]> wrote:

> On Thu, 31 Jan 2008 17:19:12 +0000, Sebastien Lambla <[email protected]>
> wrote:
>
> >Just like we moved away from unmanaged to managed, and to IoC (after all,
> >the new keyword works well enough, doesn't it?), leaving On and adopting
> >Raise / Handle seems justifiable. I find the argument of adoption to be
> >accurate but limiting.
>
> "new" isn't good enough in most IoC situations.  You use IoC to decouple
> implementation, no correct usage of "new" would allow you to do that.
>
> You can still correctly implement OnXXX...  If you find that your
> developers have a problem with the OnXXX pattern (i.e. they don't know
> enough that its intention is to raise an event) then you have more serious
> issues...
>
> http://msdn2.microsoft.com/en-us/library/wkzf914z.aspx seems pretty clear
> to me.
>
> Adding a RaiseXXX pattern is fairly benign and does make it more clear
> (without reading documentation) but offers no more guarantees that
> developers will use it more correctly than OnXXX.  It does introduces yet-
> another-way the programmer has to do something.  If they're doing a lot of
> Form programming and must deal with the OnXXX pattern, a RaiseXXX pattern
> could be viewed as just adding friction.
>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com