Not my hobby horse to ride, but I'm pretty sure the answer is because interfaces aren't nearly as "meta" as generics.
If I have an interface, I know certain things about its API, and I know that my IDE can take me to the definition of that type-contract. If I have a generic type variable, I know literally nothing about it, and there's no "definition" I can refer to, as it's my client code's decision what to parameterize my type with, and multiple clients will likely make different decisions... having a visual indicator of the non-intrinsic-ness of a given identifier is, well, marginal to me personally, but I can see it being useful. On Tue, Oct 28, 2008 at 4:42 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: > > > We don't want something that is completely "consistent with other > standard identifiers" > > [Isaac], because the entities being identified are pretty unique. > > I still disagree on this point. Generics are the next logical step, > after interfaces, in the progression from concrete types to greater > abstraction. Why brand generics and not interfaces? > > > > On Tue, Oct 28, 2008 at 4:26 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > > If we're going to differ from the community, the onus is on us have a > very > > good reason to do so. I don't think we have one, and thus my preference > for > > the single letter names. > > > > That said, Freeland's <E, E, E> case is not contrived, and it seems > foolish > > to be so rigid as to forbid using something more expressive *when it's > > clearly necessary*. My hope is that we can agree upon a long-name variant > > that still smells different than a plain old class name. We don't want > > something that is completely "consistent with other standard identifiers" > > [Isaac], because the entities being identified are pretty unique. > > It's this unique-smell test that makes me react against the Type suffix. > > It's not like it only shows up in parameterized type names (especially > with > > the advent of the new event system, which is littered with Type classes). > I > > like the TFoo or FooT conventions because they echo the 90% case of plain > > old T. > > So I'd modify my proposal thus: > >> > >> Parameterized type names should be one capital letter. However, if > >> readability demands longer names (particularly due to having multiple > >> parameters), the name should be capitalized and have suffix "T". In a > >> nutshell, prefer <T> or <K, V>, and devolve to <KeyT, ValueT> if > necessary. > > > > So how does one collapse bike shed waves in GWT land? Do we vote or > > something? > > rjrjr > > On Tue, Oct 28, 2008 at 12:58 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > >> > >> > >> On Tue, Oct 28, 2008 at 3:24 PM, Isaac Truett <[EMAIL PROTECTED]> > wrote: > >>> > >>> How does a developer end up looking at a piece of code so far out of > >>> context that the use of generics isn't obvious? > >> > >> The #1 place where I run into this is when I'm stepping through other > >> people's code in a debugger. The problem is not the the type cannot be > >> looked up. After all, if you could not look up the type, good luck with > >> those one letter acronyms. > >> > >> The problem is if all other generics he/she has seen were one letter > >> acronyms, if the programmer encounters a type that is not a one-letter > >> acronym, he/she will assume that still holds true and not know that this > >> particular type could actually be a generic type, and so may miss a > critical > >> reference to a type in the subsystem they were trying to debug. > >> > >> > >> > >> > >> > >> > >> > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
