Re: Still no typedef
Wojtek <nowhere@a.com> wrote:
And it could be buried in any
of the many included header files.
Andreas Leitgeb wrote:
Fortunately not in Java :-)
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!"
--
Lew