Why don’t UI frameworks use generics?

Question

One way of looking at type safety is that it adds automatic tests all over your code that stop some things breaking in some ways. One of the tools that helps this in .NET is generics.

However, both WinForms and WPF are generics-free. There is no ListBox<T> control, for example, which could only show items of the specified type. Such controls invariably operate on object instead.

Why are generics and not popular with UI framework developers?

• ratchet freak: java.awt and javax.swing were developed before generics came to java they remained without generics to provide backwards compatibility
• FrustratedWithFormsDesigner: You can get close with .NET with a solution like this: stackoverflow.com/questions/1592212/…

Answer 1

WinForms came with .NET 1.0 before there was support for generics. In the case of WPF, development started on that before the Framework supported generics as well. Although generics support came to .NET before WPF was released, it would have taken substantial effort to go back and add it in.

Also, the XAML to represent generics is not pretty

• Roman Starkov: I get the impression that XAML was never meant to be hand-written, which makes the ugliness argument moot. XAML is already a PITA to hand-write. As for the history thing – that’s very interesting to know, do you have a reference?
• Michael Brown: I still write most of my XAML by hand. And even when I use Blend for coarse layout and animations, I still go in and touch it up by hand after the fact. What I should have pointed out is that XAML didn't support generics in V1 (except for as part of the root element)

Answer 2

In case of WinForms it's backward compatibility with early .NET versions that didn't support generics (hence all those object senders in event handlers), while WPF implements databinding differently ({Binding Path=Name} etc.; it works by reflection).

• Roman Starkov: Is there a good reason why Binding itself can’t be generic in source and destination, implementing IBindingSource<TSrc> and IBindingDestination<TDest>?
• Konrad Morawski: @romkyns maybe because it would force you to update TSrc and TDest twice any time it is necessary (in both the class - model - and the XAML view)? I'm guessing / thinking loud

Answer 3

For a UI framework it makes much more sense to take objects and bind reflexively than to strongly-type the interfaces somehow. Lots of cases where you need to throw completely arbitrary objects into arbitrary UI containers in cases where you can't divine the types at runtime.

• Roman Starkov: ListBox<object> solves that perfectly fine, so I’m not sure this answer explains anything. And besides, 99% of the time I only put specific object types into my UIs.