Re: Consuming your own events.

Updated the entry with the correct signature, and added a lengthy reply to
Peter Ritchie's comments. By my reading of the Design Guidelines, this
pattern is compliant, and without Peter's comments, I probably wouldn’t have
bothered deliving into it to check for compliance at all.

All in all I think the pattern is now better thanks to Peter and Seb. 

--
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 Sebastien
> Lambla
> Sent: 07 February 2008 22:08
> To: [email protected]
> Subject: Re: [DOTNET-CLR] 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

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

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