At the risk of seeming to hand-wave that problem away, I would say that any Widget seeking to implement HasValue twice is not a candidate for HasValue at all. HasValue is, by definition, for Widgets with a single distinct value. The value of a CheckBox is either a String or a Boolean (we've seen arguments either way) or it simply isn't a HasValue because it's a complex Widget with two equally important and independent values.
On Thu, Dec 11, 2008 at 2:41 PM, John Tamplin <j...@google.com> wrote: > On Thu, Dec 11, 2008 at 2:20 PM, Freeland Abbott > <gwt.team.fabb...@gmail.com> wrote: >> >> To be fair, my friend was extending TextBox---which came to implement >> HasValue, and thus acquired the colliding String getValue()---when he should >> have extended Composite (which doesn't) instead; that was my suggested >> resolution for him. He grumbled ("but it 'is-a' TextBox, that should be >> extends"), but conceded. >> However, the "old" HasValue is not parameterized, and implies something >> has *string* value, period. As applied to CheckBox, that's >> confusing-to-wrong. >> Isaac is correct that we can resolve this by making CheckBox not a >> HasValue, and keep the interface... but the discussion makes me think that >> HasValue<T> has merit, and for example a CheckBox would be HasValue<Boolean> >> and a TextBox would be HasValue<String> (my friend should still make >> Composites, with HasValue<TelephoneStationNumber>, and not extend TextBox). >> But if we go with HasValue (unparameterized), that's a breaking change to >> make later (I guess we'd have to make HasTypedValue<T> instead, and have >> HasValue come to extend HasTypedValue<String>), and so I'm still happy to >> pause and think a bit more. >> (Do we like HasValue<T>, where T is widget-specific for whatever widgets >> have values??) > > One problem is that due to type erasure you cannot implement multiple copies > of this interface (such as HasValue<Boolean> and HasValue<String>). For a > hypothetical checkbox, you might well want a boolean value for checked or > not, as well as the string value (ie, what it would post as in a form > submit). > > Other than that, I think the generic version is the way to go if it is kept. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---