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 -~----------~----~----~----~------~----~------~--~---