Question: Recently I use data binding to speed up my development of C# winforms application. But I found that data binding is just useful when the control is Textbox or textare and text kind of controls. If things come to be radio button, image control or datagridview, it's hard for me to use data binding.  

 For example, it's hard for me to bind a group of radio button to a database field.  

 It's hard for me to pre-process the data in database and then bind to datagridview control(I know I can use view to do this, but it is not that convenient)  

 (another example: the vale in database is 1 and 0, I need to convert to female and male before binding datagridview) 

So I really want to know, most of you guys when will use data binding? And how will you use it ?

**EDIT:**
I know I can separate these things into different layers, but I do want to take advantage of the data binding, but while I use it, I found it is not that convenient, is there any other suffer from this ? 

**EDIT:**
but as far as i know the data binding is just like hardcode, it bind the control direct to the database field, and it's hard to make changes upon these user interface afterwards

Answer: 
The problem is that GenericTraversableTemplate is used twice: once for mutable collections (where its type parameter should be invariant), and once for immutable collections (where covariance is invariably king).

GenericTraversableTemplate's typechecks assuming either covariance or invariance for the A type parameter. However, when we inherit it in a mutable trait, we have to pick invariance. Conversely, we'd like covariance in an immutable subclass.

Since we can't abstract over the variance annotation (yet ;-)) in GenericTraversableTemplate, so that we could have instantiated it to either one depending on the subclass, we have to resort to casting (@uncheckVariance is essentially a kind-cast). For further reading, I recommend my dissertation (sorry ;-)) or our recent [bitrot paper](http://scholar.google.com/scholar?q="Fighting+bit+Rot+with+Types+(Experience+Report+Scala+Collections).")
In my thesis I describe a calculus, Scalina, that has bounds & variance annotations as part of the kind language (an earlier version is also available as a [workshop paper](http://fool08.kuis.kyoto-u.ac.jp/moors-abstract.html)). The relevance to this discussion is the next step that I want to take in developing this calculus: build another layer on top of that so that you can abstract over bounds (easy) and variance annotations (makes my head spin). Actually, you wouldn't just tack 1 extra layer on there, but rather generalise your polymorphism constructs so they work at all levels, and make your "attributes" (bounds, variance annotations, required implicit arguments,...) into regular types with special kinds, which are all subject to abstraction.

The "attributes are types" idea is explained nicely by Edsko de Vries in the context of uniqueness types.

> 
> [Uniqueness Typing Simplified](http://www.cs.tcd.ie/%7Edevriese/pub/ifl07-paper.pdf),
> Edsko de Vries, Rinus Plasmeijer, and David Abrahamson.
> In Olaf Chitil, Zoltán Horváth and Viktória Zsók (Eds.):
> IFL 2007, LNCS 5083, pp. 201-218, 2008.
> 
> 
> Abstract: We present a uniqueness type
> system that is simpler than both
> Clean's uniqueness system and the
> system we proposed previously. The new
> type system is straightforward to
> implement and add to existing
> compilers, and can easily be extended
> with advanced features such as higher
> rank types and impredicativity. We
> describe our implementation in Morrow,
> an experimental functional language
> with both these features. Finally, we
> prove soundness of the core type
> system with respect to the
> call-by-need lambda calculus.
> 
> 
>