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