Chris rant reminded me about something I thought of in regards of the Windows Forms design.
A lot of the Winforms technology is cool. Many controls are easy to use, and things like the way layout works with docking and anchoring is really cool and useful. However, if you look at the larger picture of the Winforms library design, you'll realize a large portion of it sucks.
Why? Chris already mentioned part of it indirectly in his rant: Too much of it relies on base classes to work. Why didn't they rely more on well defined interfaces instead of base classes?
Much of this leads to what I consider really weird looking class hierarchies. For example, the familiar concept of a "window" is pretty well hidden underneath the whole framework. As for the Control base class... can it suck more? It makes no sense to me to have the concept of a Form be an instance of the Control abstraction. I consider them to be fundamentally different things because their usage model is, overall, too different. Instead, I would've liked to see the Window abstraction as a base pattern, with Forms and Controls being two separate abstractions built on top of it.
And while on the subject: Form? Blagh!
Likewise, one could argue against several other Winforms abstractions and particularly agains conventions.... why does the Control class offer like 7 different ways to take a control's position and size, with only some of them being directly updatable? Hell, why couldn't we have only one or two? Is there no consistency and simplicity in our world anymore?
I don't do much Winforms coding these days, but I did quite a bit before. I always found it weird that at times I was missing MFC so much, and that's even though I haven't written a single line of MFC code in like three years!
