Re: Consuming your own events.

You're quite right and of course you can use Raise(EventArgs). It all
depends on the contract you want to achieve with your inherited classes, but
it doesn't change the pattern I'm proposing.

I'll update the post to highlight this point though.

--
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 Sébastien
> Lorion
> Sent: 07 February 2008 18:16
> To: [email protected]
> Subject: Re: [DOTNET-CLR] 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

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

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