That feedback sounds a bit pedantic and impractical to me. And my job title used to be Senior Pedant.
On Tue, Feb 24, 2009 at 7:44 AM, Emily Crutcher <[email protected]> wrote: > It could work, though I found when I used this technique with > DatePicker (DatePicker extends AbstractDatePicker<MonthSelector, > CalandarView>), there was some feedback that having that abstract type layer > was slightly confusing because good OO practice implied that references > should then be typed as AbstractDatePicker, which then brought in the > complexity of the generic types back into the lives of the 90% who did not > care about the parameterized arguments. > > > > > > > > > On Tue, Feb 24, 2009 at 10:00 AM, Ray Ryan <[email protected]> wrote: > >> How about extracting a parameterized super class: >> AbstractSuggestionBox<T extends Suggestion> >> SuggestionBox extends AbstractSuggestionBox<Suggestion> >> >> rjrjr >> >> On Mon, Feb 23, 2009 at 7:15 PM, Emily Crutcher <[email protected]> wrote: >> >>> >>> >>> On Mon, Feb 23, 2009 at 7:04 PM, Isaac Truett <[email protected]> wrote: >>> >>>> >>>> The API documentation has this to say on the subject: >>>> >>>> "[...] To send back a DTO with each suggestion, extend the Suggestion >>>> interface and define a getter method that has a return value of the >>>> DTO's type. Define a class that implements this subinterface and use >>>> it to encapsulate each suggestion. >>>> >>>> To access a suggestion's DTO when the suggestion is selected, add a >>>> SuggestionHandler to the SuggestBox (see SuggestBox's documentation >>>> for more information). In the >>>> SuggestionHandler.onSuggestionSelected(SuggestionEvent event) method, >>>> obtain the selected Suggestion object from the SuggestionEvent object, >>>> and downcast the Suggestion object to the subinterface. Then, acces >>>> the DTO using the DTO getter method that was defined on the >>>> subinterface." >>>> >>>> See >>>> http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/user/client/ui/SuggestOracle.Suggestion.html >>>> >>>> (the 1.6 version is similar, but with the new event model) >>>> >>>> So the endorsed solution is to extend and cast. Fair enough. This >>>> probably dates from pre-1.5, and it was good enough for then. But is >>>> there a reason not to parameterize SuggestBox with <T extends >>>> Suggestion> (and SuggestOracle<T>, SelectionEvent<T>, etc.) now that >>>> that's an option? Or perhaps make Suggestion implement HasValue<T>? I >>>> have an application that uses many SuggestBoxes and many different >>>> Suggestion subclasses and this would simplify things (and eliminate >>>> much type-casting). >>> >>> >>> I'm not sure parameterizing SuggestBox itself would be worth it, as most >>> people use it without creating new types of suggestions: so the >>> parameterization would add clutter for the many and prevent casts for the >>> few. Though, I completely agree it is annoying to have to cast. Perhaps we >>> could create a composite-based CustomSuggestBox that is parameterized? >>> >>> >>> >>>> >>>> >>>> Any thoughts on this? Horrible side effects that I'm missing? >>>> >>>> - Isaac >>>> >>>> >>>> >>> >>> >>> -- >>> "There are only 10 types of people in the world: Those who understand >>> binary, and those who don't" >>> >>> >>> >>> >> >> >> > > > -- > "There are only 10 types of people in the world: Those who understand > binary, and those who don't" > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
