+1 for option 2. And I think Bob's Person/MutablePerson scenario is a hugely compelling justification for it. I also wonder if something as obscure as the monomorphicSingleImpl flag will ever be found. If the performance issue really is a big enough concern to warrant its implementation (I can't judge it), would it make sense to provide a compiler warning when multiple implementations are found, which document the flag? Or perhaps allow/require them to be defeated by an @SuppressWarning?
rjrjr On Wed, Jan 7, 2009 at 10:15 AM, Emily Crutcher <e...@google.com> wrote: > FormPanelImplHost is an example of an impl interface. > > I think once users see one *Impl type that has documented useful > functionality for them, they are less likely to ignore the next *Impl > class/interface/annotation they see that looks like it might be useful for > them, regardless of whether the *Impl type is an annotation, interface, or > class. > > > > On Wed, Jan 7, 2009 at 12:26 PM, Bruce Johnson <br...@google.com> wrote: > >> @Emily: Does the fact that it's an annotation not make it completely >> clear? We don't use *Impl on interfaces anywhere (do we?) >> >> On Wed, Jan 7, 2009 at 11:46 AM, Emily Crutcher <e...@google.com> wrote: >> >>> In the library code we constantly use *Impl to denote a class that users >>> should not look at, but here we we have *Impl annotations that is part of a >>> public API. Could we modify the name slightly so we can keep the *Impl >>> convention consistant throughout the gwt code base? >>> >>> >>> On Wed, Jan 7, 2009 at 11:17 AM, John Tamplin <j...@google.com> wrote: >>> >>>> On Wed, Jan 7, 2009 at 10:48 AM, Bruce Johnson <br...@google.com>wrote: >>>> >>>>> Does anyone buy that reasoning? An important related question is >>>>> whether these things are actually compiler flags or whether they are >>>>> module >>>>> settings. I think they are actually more appropriate as the latter. >>>>> >>>> >>>> If they are module flags, what happens when you have different settings >>>> for different modules (as you point out, it will be impossible to keep them >>>> consistent in a large code base with shared code)? If it is a compile-time >>>> error, then some code simply won't be shareable between projects -- maybe >>>> that is ok if that module's owner has decided it is important enough to set >>>> the flag in a library module? If it is based on which module it is in, >>>> does >>>> the caller or callee win the battle, and will that behavior be surprising >>>> to >>>> a developer? >>>> >>>> Regarding the original question, I don't have a strong preference for >>>> either solution over the other. #2 does have additional utility, but it >>>> seems less consistent than simply saying that after type tightening there >>>> must be exactly one implementation. Given the primary use case is shared >>>> code between client and server which will use a JSO object in the client >>>> (at >>>> least until generators are able to produce a JSO subclass), I am not sure >>>> the additional utility is worth the hidden code size risk and slightly >>>> inconsistency. >>>> >>>> -- >>>> John A. Tamplin >>>> Software Engineer (GWT), Google >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> "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 -~----------~----~----~----~------~----~------~--~---
