Sunday, August 07, 2005

Huh?

I've been reading up on java 5.0 and I came across this tutorial on the new generics framework.
A note on naming conventions. We recommend that you use pithy (single character
if possible) yet evocative names for formal type parameters.

Huh? I couldn't believe my eyes and what I was reading. But, here's the code sample:
public interface List<E> {
void add(E x);
Iterator<E> iterator();
}
public interface Iterator<E> {
E next();
boolean hasNext();
}

I can see why so many java advocates have been clamoring about the complexity. Shouldn't we be making the code more readable? The paper goes through the problems with generics and addresses each one. It leaves you asking yourself, "Is this going too far?" It especially gets messy around how to treat subclasses and interfaces. The answer makes everything more restrictive which sounds good on paper (if you like type safety), but it also reduces polymorphic possibilities. I shutter at the thought of the code that I will come across from inexperienced OO developers. Much like I have seen "private" misused in method declarations. I expect to see generics misused to be more restrictive that they need to be as well. I applaud the effort to reduce the need to type cast, but what price shall we pay for safety? Generics do make like easier for some issues, but it complicates others. Is it really worth it? I find unit tests a much better tool to fix type issues than enforcing type safety.

11 comments:

Isaac Gouy said...

"Shouldn't we be making the code more readable?"
I'd be interested in seeing your idea of a more readable alternative for those interface definitions - particularly a more readable alternative for 'E'

Samuel Tesla said...

This is why I don't particularly care for generics/templates. It's a tradeoff in readability for something that dyamic languages get for free.

As far as a better name for 'E', Mr. Gouy, we've been doing this for a long time in dynamic languages (reflecting and passing class references around). I'd be inclined to call it 'ElementClass' or 'ElementType' if you want to convey that you can use it with primitives. The whole idea is that you'll type it once but read it a thousand times, so make it express something.

Isaac Gouy said...

Samuel, I feel it would be unfair to respond to your comments, as Blaine has failed to reproduce the example correctly.

(Here's the example using square-brackets instead of angle-brackets)

public interface List[E] {
void add(E x);
Iterator[E] iterator();
}

public interface Iterator[E] {
E next();
boolean hasNext();
}

Ravi Venkataraman said...

The point of Blaine's post was that it was unusual, and contrary to accepted naming practices, to name a variable with a single letter.

The fact that Sun recommends it is astonishing.

The fact that Blaine omitted some syntax elements is completely irrelevant to his argument.

Ravi

Isaac Gouy said...

Ravi, the quotation specifically states formal type parameters it doesn't say "name a variable with a single letter".

Isaac Gouy said...

we've been doing this for a long time in dynamic languages
We might have been "reflecting and passing class references around" but we sure haven't been naming formal type parameters.

Isaac Gouy said...

Huh? I couldn't believe my eyes and what I was reading
I have much the same reaction when I find that the sentence following the one Blaine quotes gives the rationale for the naming convention.

"making it easy to distinguish formal type parameters from ordinary classes and interfaces"

iow everyone knows better than to use single letter names for classes and interfaces - so when we see a single letter name, we can be confident the parameter is not a class or an interface but is a formal type parameter.

Samuel Tesla said...

I started to write a response here, and realized that it was big enough to be a post of its own. It's over here on my blog.

As far as reflection and class references. Yes, exactly. That's my point. We Don't Have To Do This Crap. In dynamic languages we can get all of the benefits that generics bring to statically typed languages without all of the nasty readability problems. Not to mention the complexity bloat.

Static typing is a language designer's way of saying he thinks programmers are too stupid to write software and that he must make the computer catch their mistakes. Generics are static typing's way of approximating the things that dynamic languages can do because dynamic languages trust the programmer to be smart.

Isaac Gouy said...

Samuel: no secret that the next version of Java will have generics
Ummm hasn't Java had generics for almost a year?

Matrix[E, F]
Of course sometimes we deal with hypercubes made up of strings and doubles and dates and... If we're just doing matrix math, wouldn't all the elements be the same type, irrespective of the number of dimensions? Matrix[T]

It's funny how often we complain about the rhetoric thrown against Smalltalk by people who've never used the language, but then we don't seem at all inhibited in lambasting something we haven't used ;-)

Anonymous said...

sexual

Anonymous said...

sexual

Amazon