Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Joshua Cranmer <Pidgeot18@verizon.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: diamond operator
Date: Fri, 06 Apr 2012 21:35:51 -0500
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <jlo96d$akk$1@dont-email.me>
References: <n4ann71plharl1ank5424uvqdi2ffpfh67@4ax.com> <2pmx6r31q4.fsf@shell.xmission.com> <4f7ec03d$0$6932$e4fe514c@news2.news.xs4all.nl> <13661523.578.1333734815811.JavaMail.geo-discussion-forums@pbcr5>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 7 Apr 2012 02:35:57 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="WpcHJSul77m+zlbR9GVqkA"; logging-data="10900"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+AYK5LV2159wSZ9UKdD3j0fuzIj4XwAok="
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
In-Reply-To: <13661523.578.1333734815811.JavaMail.geo-discussion-forums@pbcr5>
Cancel-Lock: sha1:m6CKoZRN3d4M8IDYyjJ/FTHKtAs=
Xref: csiph.com comp.lang.java.programmer:13447

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