If that concern doesn't seem like it would be a problem, then I definitely agree with you that creating abstract base classes that have the parametrized types seems like the best solution.
On Tue, Feb 24, 2009 at 10:54 AM, Ray Ryan <rj...@google.com> wrote: > 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 <e...@google.com> 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 <rj...@google.com> 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 <e...@google.com> wrote: >>> >>>> >>>> >>>> On Mon, Feb 23, 2009 at 7:04 PM, Isaac Truett <itru...@gmail.com>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" >> >> >> > > > > -- "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 -~----------~----~----~----~------~----~------~--~---
