Re: Consuming your own events.

Asp.net event handling hooking uses OnXxx=delegate... IE uses onclick...

Most of the developers I work with are using the OnXxx for handling events
because they're web devs and it makes sense to them...

You raise interesting questions. But me worrying about how people use my API
and not having the right reaction when overriding a virtual is an issue, and
one that has caused quite a few long-running bugs over the year.

If you need to rely on analysis tools for errors like those, I still
consider that your contract wasn't strong enough.

I think we've reached the point where I'm on my own in this quest, so I'll
leave it at that for now.

--
SerialSeb
http://serialseb.blogspot.com


> -----Original Message-----
> From: Discussion of development on the .NET platform using any managed
> language [mailto:[email protected]] On Behalf Of James
> Geall
> Sent: 31 January 2008 21:32
> To: [email protected]
> Subject: Re: [DOTNET-CLR] 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 DevelopMentorR  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