Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #13447

Re: diamond operator

Show all headers | View raw

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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

diamond operator Roedy Green <see_website@mindprod.com.invalid> - 2012-04-03 18:54 -0700
  Re: diamond operator Arne Vajhøj <arne@vajhoej.dk> - 2012-04-03 22:06 -0400
  Re: diamond operator Silvio Bierman <silvio@moc.com> - 2012-04-04 13:12 +0200
    Re: diamond operator David Lamb <dalamb@cs.queensu.ca> - 2012-04-04 08:23 -0400
      Re: diamond operator Silvio Bierman <silvio@moc.com> - 2012-04-04 15:40 +0200
      Re: diamond operator Arne Vajhøj <arne@vajhoej.dk> - 2012-04-04 19:41 -0400
        Re: diamond operator David Lamb <dalamb@cs.queensu.ca> - 2012-04-05 08:03 -0400
  Re: diamond operator Jim Janney <jjanney@shell.xmission.com> - 2012-04-04 10:23 -0600
    Re: diamond operator Lew <lewbloch@gmail.com> - 2012-04-04 18:15 -0700
      Re: diamond operator David Lamb <dalamb@cs.queensu.ca> - 2012-04-05 15:44 -0400
        Re: diamond operator Jim Janney <jjanney@shell.xmission.com> - 2012-04-05 14:54 -0600
    Re: diamond operator Silvio Bierman <silvio@moc.com> - 2012-04-06 12:06 +0200
      Re: diamond operator Lew <lewbloch@gmail.com> - 2012-04-06 10:53 -0700
        Re: diamond operator Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-04-06 21:35 -0500
          Re: diamond operator Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 20:07 -0400
      Re: diamond operator Jim Janney <jjanney@shell.xmission.com> - 2012-04-06 19:56 -0600
        Re: diamond operator Jim Janney <jjanney@shell.xmission.com> - 2012-04-06 20:02 -0600
  Re: diamond operator Arivald <NOSPAMarivald@interia.pl> - 2012-04-05 10:11 +0200
    Re: diamond operator Lew <lewbloch@gmail.com> - 2012-04-05 11:34 -0700
      Re: diamond operator Arivald <NOSPAMarivald@interia.pl> - 2012-04-05 22:02 +0200
        Re: diamond operator ObeseeExpen <ObeseeExpen.5ibto0@no-mx.forums.yourdomain.com.au> - 2012-09-03 12:39 -0400
      Re: diamond operator Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-04-05 18:18 -0500
      Re: diamond operator Arne Vajhøj <arne@vajhoej.dk> - 2012-04-05 19:38 -0400
      Re: diamond operator Silvio Bierman <silvio@moc.com> - 2012-04-06 17:07 +0200
        Re: diamond operator Thufir <hawat.thufir@gmail.com> - 2012-04-06 08:51 -0700
          Re: diamond operator Silvio Bierman <silvio@moc.com> - 2012-04-08 15:12 +0200
    Re: diamond operator Arne Vajhøj <arne@vajhoej.dk> - 2012-04-05 19:41 -0400

csiph-web