Re: Consuming your own events.

sorry, SerialSeb

but after reading through most of the comments on this thread, the article refered to by Peter Ritchie, I have to agree with Peter and some others.

IMHO the On<TheEvent> model pattern/model defined by Microsoft is good-enough (and implemented consistently in the BCL) for simple event handling and that the introduction of a new version isn't justified. For more complex event cases I still argue that callback interfaces that reflect the complete protocol is the sustainable approach; (such cases could handle so many more aspects of event:ing that I'm note even sure that it should be called event:ing, it is more a message-passing system).

regards,
  Daniel

________________________________________
From: Discussion of development on the .NET platform using any managed              language [[email protected]] On Behalf Of Sebastien Lambla [[email protected]]
Sent: Friday, February 01, 2008 9:35 AM
To: [email protected]
Subject: Re: [DOTNET-CLR] Consuming your own events.

RaiseXxx / HandleXxx pattern, and explicit Before/After or Cancelable events
when an event can or should be cancelled.

I'm also objecting to the idea that all methods are non virtal by default
but all event raising methods are virtual.

--
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 silky
> Sent: 31 January 2008 23:52
> To: [email protected]
> Subject: Re: [DOTNET-CLR] Consuming your own events.
>
> On Feb 1, 2008 10:07 AM, Sebastien Lambla <[email protected]> wrote:
> > 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.
>
> Seb, I may have missed it in amongst all the posts; but what do you
> propose instead of the "OnXXX" approach?
>
>
> > --
> > SerialSeb
> > http://serialseb.blogspot.com
>
> --
> http://lets.coozi.com.au/
>
> ===================================
> 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

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

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