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