I strongly agree with Chris Dollin

Same here, especially with an IDE that lets me see how the name is
declared whenever I need to know that.

Patricia

Me, four  (after two more followup'ers) :-)

I feel that the burden of proof is on the typedef proponents to show how it
would serve in a more complex example.  Nevertheless, I provided such an
example and how it actually does not favor typedef, in another part of this
thread.

Wojtek <nowhere@a.com> wrote:

Imports could be just as bad.  If the typedef were importable, it'd be no more
useful for self-documenting code than a raw type is.

I don't think the verbosity of generic types is wasted or redundant or
unnecessary or even undesirable.  The type arguments are the /raison d'être/
of generics, and they do often "alias" to single-letters, at least in the
declarations:

public class Foo< T extends Comparable<? super T> >
{
  T member; // all the benefits of typedef in here
}

OK, let's return to the iterator example, which is verbose, I agree.

 List <Foo<Comparator<Integer>> stuff
  = new ArrayList  <Foo<Comparator<Integer>>  ();

 Iterator <Foo<Comparator<Integer>> iter = stuff.iterator();

 for ( Foo<Comparator<Integer> foo; iter.hasNext(); )
 {
  foo = iter.next();  // phew, by hear at least all that verbiage is gone
 }

Of course, the syntactic sugar in this particular use case is already present
in the enhanced for loop. so typedef would only be useful for other iterator
scenarios, such as when you remove() or add() through an iterator.  Let's
pretend this is that.

The typedef would add one line of code and reduce the generic overhead from
four repetitions to one.

 typedef FooInt Foo<Comparator<Integer> FooInt;

 List <FooInt> FooList stuff
  = new ArrayList <FooInt>  ();

 Iterator <FooInt> iter = stuff.iterator();

 for ( FooInt foo; iter.hasNext(); )
 {
  foo = iter.next();  // phew, by hear at least all that verbiage is gone
 }

Of course, that only got rid of part of the overhead.  Now we need another
typedef to get rid of the FooInt.

 typedef FooInt Foo<Comparator<Integer> FooInt;
 typedef  List <FooInt> FooIntList;

 FooIntList stuff
  = new ArrayList <FooInt>  ();

 Iterator <FooInt> iter = stuff.iterator();

 for ( FooInt foo; iter.hasNext(); )
 {
  foo = iter.next();  // phew, by hear at least all that verbiage is gone
 }

Huh, that only got one out at the cost of one, plus a whole typedef line.  The
same would happen for ArrayList <FooInt> and Iterator <FooInt>.  Plus all
these typedef names would start to be an overhead of their own, having to
remember their meaning as well as the more common "List", "ArrayList" and
"Iterator".

 List <Foo<Comparator<Integer>> stuff
  = new ArrayList  <Foo<Comparator<Integer>>  ();

 Iterator <Foo<Comparator<Integer>> iter = stuff.iterator();

 for ( Foo<Comparator<Integer> foo; iter.hasNext(); )
 {
  foo = iter.next();  // phew, by hear at least all that verbiage is gone
 }

In certain ways the original is clearer, at least to me. The words "List",
"ArrayList", "Iterator" and "Foo" leap out at me, and the generic stuff
remains noise until I focus on it, at which point it provides a nice safe
feeling of matching types.  So in casual reading I see the raw types, and
algorithm is perfectly readable.  In detailed reading the detail is only
slightly more dense than what a typedef would show.

So to typedefs in Java, I say, "Pllpppllplpllpppttthh!"

I guess I understand what people think typedef will do, but I just don't have
such a hard time using List <String>.

And who uses fully-qualified names when they're griping about doing too much
typing?

I really don't even have trouble with Entity< Node, Renderer > either.  Or
even Entity <Node, Renderer, Comparator< ? super Node >>.  Or Map <Node,
Integer>.  To my eye the typedef would just hide the vital information
revealed in the generics.

I would not favor adding "typedef" to the language.  Just one more thing that
hides what a type is, making you look elsewhere in the code to understand it,
just because someone is too lazy to (let the IDE) type the generic types.

It does.

But considering that Java source code and Java byte code is very 1:1
then the difference is not big.

Arne