Re: diamond operator
On 4/6/2012 12:53 PM, Lew wrote:
And, as I said earlier, that doesn't in the least prevent me from
saving those yoctoergs myself. It's for readability, which actually
is a distinct advantage of the diamond operator. I'm surprised no one
else proffered that one real engineering advantage before this.
The original proposal for the diamond operator (formally, "Improved Type
Inference for Generic Instance Creation") mentions the following for its
advantage section (from
<http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000009.html>):
Generics have had a tremendously positive impact on type safety in
the Java programming language. They have made it possible to provide
static guarantees about the type of instances used by other classes,
preventing entire classes of runtime errors from occurring. However,
generics have added complexity to Java, making the code far more
verbose and occasionally difficult to read. Although solving this
problem is well outside the scope of this proposal, a limited form of
type inference would remove unnecessary redundancy from the
language.
The requirement that type parameters be duplicated unnecessarily like
this encourages an unfortunate overabundance of static factory
methods, simply because type inference works on method invocations.
For example, the Google collections library [2] contains a class that
wraps every possible constructor of every subclass of java.util.List
in the JDK:
public class Lists {
public static <E> List<E> newArrayList() { return new ArrayList<E>(); }
public static <E> List<E> newArrayList(int i) { return new ArrayList<E>(i); }
// ...
}
List<String> list = Lists.newArrayList();
This approach avoids the redundancy in the declaration, but requires
two declarations for every possible constructor in every possible
class. This is ugly: every time a constructor or a new subtype of
List is created, this class must be updated. Furthermore, the names
of these methods does not have to be consistent; there is no reason
to favor newArrayList over createArrayList. The proposed feature
would make this approach obsolete.
At least according to this post, people have invented awkward ways to
get around the lack of a diamond operator. The author also discusses
loosely the idea of actually introducing something like `auto' but has
also admitted that he kept it smaller since Project Coin was focused on
small features. There is also apparently some discussion on the full
corner cases on this feature (I bet you didn't know it had any :-P ...
type inference is really nontrivial to formally specify).
Note that the author also highlighted (by implication) that the diamond
operator removes redundancy, enhances readability, and reduces verbosity.
Also interesting is that later discussion seems to indicate a body of
people who disapprove of a hypothetical `auto' keyword even while
approving of the diamond operator, specifically because of a dislike of
implicit typing.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth