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