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

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

Re: diamond operator

Show all headers | View raw

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

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

Thread

Re: diamond operator Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 20:07 -0400

csiph-web