+1 to that comment. BTW, I didn't realize your title *actually* used to be Senior Pedant. That's even better than my old friend Charlie, whose title was "Senior Bit Twiddler" (he was a CompE after all...)!
On Tue, Feb 24, 2009 at 10:56 AM, Ray Ryan <rj...@google.com> wrote: > HasValue<T extends Suggestion> sounds wrong to me. The suggestions are not > the value that we're getting from the user, they're prompts to the user to > help her get to the actual value. I'd much more expect a SuggestionBox to be > HasValue<String> -- it's just a TextBox that happens to have chats with the > server. > rjrjr > > > On Tue, Feb 24, 2009 at 7:24 AM, Isaac Truett <itru...@gmail.com> wrote: > >> >> I like the super class. I'm not sure it actually needs to be abstract. >> I think that by adding HasValue<T> to Suggestion we can do it with >> concrete classes. >> >> TypedSuggestBox<T> (SuggestBoxBase?) >> Suggestion<T> implements HasValue<T> >> SuggestOracle<T> >> SuggestBox extends TypedSuggestBox<String> >> MultiWordSuggestOracle extends SuggestOracle<String> >> >> That should cover my use case and, I think, minimize impact on anyone >> using only the plain String suggestions. >> >> >> >> >> 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" >> >> >> >> >> > >> > >> > > >> > >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
