Re: Consuming your own events.

My point is that maybe (I stress maybe) WPF could have made it so that
its architecture respect the established pattern of OnXXX. Is that
pattern perfect? no. But then, is there any perfect pattern? But
that's the one we got, it's a fundamental one, and now people need to
learn yet another way of doing things *again*.

And that was my other point. I am personally very tired of having to
learn new things for the sake of it. What I meant with
"meta-framework" (bad term I know) is an API to do *basic* stuff your
typical n-tier app does without having to learn a new way to do it
over and over and over ... See
http://www.codinghorror.com/blog/archives/000916.html. And that is
related to the first point by my belief that the OnXXX pattern could
have been respected in WPF if it had been a priority. Now maybe I am
wrong on this, but I see no compelling reasons to think otherwise.

Sébastien

On 1/31/08, Sebastien Lambla <[email protected]> wrote:
> > In case of framework/library code, I would favor consistency over
>  > correctness. Maybe your solution has some problems attached to it too.
>  > When you find out about it, what will happen? A fourth pattern? Being
>  > that the official guideline and the vast majority of .NET code use the
>  > OnXXX pattern, I will go that way.
>
>
> I favour correctness in a new implementation. Just because everybody uses
>  one method (most of the time in the wrong way) deosn't mean we have to live
>  with it.
>  Then again, as long as a pattern is followed accurately and defend itself
>  against coding practices that tarnished the previous pattern, it will get
>  adopted. If it has flaws another one will replace it. That's natural
>  selection, and something software engineers are very much used to.
>  But maybe that's a conversation for alt.net, not for this list.
>
>
>  > Also, as others have pointed out, most of the time I override the
>  > OnXXX method is because I want to control the execution order (very
>  > useful in ASP.NET). It is also useful to patch buggy controls which
>  > raise events when they should not.
>
>
> Let's not confuse supporting existing APIs and writing new ones. Your use of
>  OnXxx on existing frameworks is a given.
>
>
>  > If something smells fishy to me, it's WPF and the hoops it needs to go
>  > through to raise events. Looks like leaky implementation ...
>
>
> I fail to see how any of this is fishy. WPF solves problems in a different
>  way, and the event and DP system is solving a different kind of problems.
>  Looking leaky and smelling fishy are definitely not how i would describe
>  this API.
>
>
>  > On a related note, binding, control validation and many other things
>  > works differently in WPF, Winforms and ASP.NET. Would it be nice that
>  > we get one "meta" model that can be used in all of them. Sure! Will we
>  > get that one day? I doubt it.
>
>
> If you believe in meta models, or even that they can exist, you're living in
>  a software world that must be very different to mine.
>
>  New APIs replace the previous ones to provide more power. WPF Databinding is
>  significantly more powerful than Winforms one, so naturally it comes with a
>  different architecture. I don't see any issue in this.
>
>  And I fail to see what all those points have to do with the shapeshifting
>  abilities of the OnXxx anti-pattern.
>
>
>  --
>  SerialSeb
>
>  ===================================
>  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