Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > diamond operator

Reply
Thread Tools

diamond operator

 
 
Lew
Guest
Posts: n/a
 
      04-06-2012
Silvio Bierman wrote:
> Jim Janney wrote:
>> Roedy Green writes:
>>> I was looking over the table of contents of a book about new features
>>> in Java 7 and came across a reference to the "diamond operator".
>>>
>>> It turns out to be simple, but one of the precious bits of Java
>>> syntactic sugar to make it terser.
>>>
>>> http://fahdshariff.blogspot.ca/2011/...-operator.html
>>>
>>> http://mindprod.com/book/9781849685627.html

>>
> > This isn't wrong, but it fixes a problem I never knew I had. Any
> > competent IDE will expand that for you anyway.
> >

>
> IDE support is irrelevant in this discussion. Language syntax is not
> about typing.


It is most certainly not irrelevant. Language support for the diamond operator was motivated by the desire of a certain constituency to avoid typing. The kind you do on a keyboard, not the kind to declare variables.

The language itself was just fine with redundant expression of generic parameters. Every known source editor supports search-and-replace, so the refactoring effort is identical with or without the diamond operator. Every known source editor supports copy-and-paste, so there is not a whole lot of difference in yoctoergs exerted to write generic expressions. So am I harsh tojudge the laziness and pettifogging petulance of those who clamored for the feature? Not hardly; if anything I'm being forgiving.

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.

--
Lew

>
> Code needs to be read and reasoned about. The better the syntax, the
> less reading effort needed to be able to reason. Java's redundant syntax
> in this respect is inefficient and the diamond operator takes away part
> of that.


 
Reply With Quote
 
 
 
 
Jim Janney
Guest
Posts: n/a
 
      04-07-2012
Silvio Bierman <(E-Mail Removed)> writes:

> On 04/04/2012 06:23 PM, Jim Janney wrote:
>> Roedy Green<(E-Mail Removed)> writes:
>>
>>> I was looking over the table of contents of a book about new features
>>> in Java 7 and came across a reference to the "diamond operator".
>>>
>>> It turns out to be simple, but one of the precious bits of Java
>>> syntactic sugar to make it terser.
>>>
>>> http://fahdshariff.blogspot.ca/2011/...-operator.html
>>>
>>> http://mindprod.com/book/9781849685627.html

>>
>> This isn't wrong, but it fixes a problem I never knew I had. Any
>> competent IDE will expand that for you anyway.
>>

>
> IDE support is irrelevant in this discussion. Language syntax is not
> about typing.
>
> Code needs to be read and reasoned about. The better the syntax, the
> less reading effort needed to be able to reason. Java's redundant
> syntax in this respect is inefficient and the diamond operator takes
> away part of that.


I agree on the importance of readability, but as far as I can tell the
diamond operator offers only a fairly minor improvement there: the 1.4
syntax is redundant, yes, but not error prone. When looking at code
like

Map<String, List<Pair<Int, Double>>> m = new HashMap<String, List<Pair<Int, Double>>>();

I don't need to study the second list of types looking for subtle
mistakes: it's either correct or it won't compile.

--
Jim Janney
 
Reply With Quote
 
 
 
 
Jim Janney
Guest
Posts: n/a
 
      04-07-2012
Jim Janney <(E-Mail Removed)> writes:

> the 1.4
> syntax is redundant, yes, but not error prone.


Sorry, 1.5 syntax of course.

--
Jim Janney
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      04-07-2012
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 ...
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
 
Reply With Quote
 
Silvio Bierman
Guest
Posts: n/a
 
      04-08-2012
On 04/06/2012 05:51 PM, Thufir wrote:
> On Fri, 06 Apr 2012 17:07:49 +0200, Silvio Bierman wrote:
>
>> Typing is irrelevant. Laving out the left hand type increases
>> readability by removing redundancy. In a different world your example
>> could have been
>>
>> auto map = new Map<Integer,List<String>>();
>>
>> Any keyword as a replacement for auto would work.

>
> While I'm familiar with neither Scala nor Haskell, that seems a bad
> idea. What happened to the idea of using a, for example, Ferrari
> interface on a Car instance? Sure, the object is a Car, but that Ferrari
> interface is used, well, not for convenience per se, but as a reminder
> that this Car is not *just* a Car.
>
> You're suggestion is completely contrary to that principle. While I
> appreciate that it's easier, I don't get the point.
>
> That being said, in Ruby you instantiate with:
>
> foo = Bar.new
>
> which is quite nice and simple.
>
>
>
> -Thufir


I will counter this with a Scala example.

This is the minimal version:

val map = new HashMap[Int,List[String]]

giving "map" the "Ferrari" type.

But you could also have:

val map : Map[Int,List[String]] = new HashMap[Int,List[String]]

giving "map" the "car" type explicitly.

Ruby is a completely different animal being dynamically typed. It is
however an example of the power of type inference that Scala and Haskell
can approach the notational convenience of Ruby while being statically
typed.

 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      05-06-2012
On 4/6/2012 10:35 PM, Joshua Cranmer wrote:
> 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.


One of those recommending the factory to get type inference
is a well known guy with same last name as Lew.

Arne

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Odd behavior of operator=() in diamond inheritance situation Juha Nieminen C++ 1 03-02-2009 12:00 PM
translate Perl diamond operator to Ruby Chad Perrin Ruby 11 04-16-2007 07:03 PM
MSI P4N Diamond NF4-SLI Intel Edition Motherboard Review Silverstrand Front Page News 0 09-14-2005 08:48 PM
<> the Diamond Operator maryellen sniffen Perl Misc 3 12-31-2004 03:07 PM
binmode and the diamond operator J. Romano Perl Misc 6 11-17-2003 02:47 AM



Advertisments