Re: Consuming your own events.

In your proposed pattern:

protected virtual void RaiseSomethingChangedEvent(string paramName) {
SomethingChanged(this, new PropertyChangedEventArgs(paramName)); }

This introduces versionning issues and reduce flexibility (I cannot
use my own xxxEventArgs class derived from PropertyChangedEventArgs)
... I think both Raise and Handle methods should take an xxxEventArgs
argument.

Sébastien

On 2/7/08, Sebastien Lambla <[email protected]> wrote:
> I've written a more detailed review of the issues and proposed solution on
>  my blog, for those that are still interested in the subject.
>
>  http://serialseb.blogspot.com/2008/02/raising-event-without-checking-for-nul
>  l.html
>
>  (or when a URL goes bonkers because you change what you're talking about in
>  the middle of a post...)
>
>
>  --
>  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 Daniel
>  > Petersson
>  > Sent: 01 February 2008 11:36
>
> > To: [email protected]
>  > Subject: Re: [DOTNET-CLR] 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
>
>  ===================================
>  This list is hosted by DevelopMentor(R)  http://www.develop.com
>
>  View archives and manage your subscription(s) at http://discuss.develop.com
>


-- 
Sébastien
www.sebastienlorion.com

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

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