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

Groups > comp.lang.java.programmer > #13364 > unrolled thread

diamond operator

Back to article view | Back to comp.lang.java.programmer

Contents

  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

Page 1 of 2  [1] 2  Next page →

#13364 — diamond operator

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/07/java-7-diamond-operator.html

http://mindprod.com/book/9781849685627.html
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
When you were a child, if you did your own experiment
to see if it was better to put to cocoa into your cup first
or the hot milk first, then you likely have the programmer gene..

[toc] | [next] | [standalone]

#13365

On 4/3/2012 9:54 PM, Roedy Green wrote:
> 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/07/java-7-diamond-operator.html

It is listed in the release notes:
   http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html
that link to the docs:
 
http://docs.oracle.com/javase/7/docs/technotes/guides/language/type-inference-generic-instance-creation.html

It was probably also discussed here last summer when
Java 7 was released.

Arne

[toc] | [prev] | [next] | [standalone]

#13367

On 04/04/2012 03:54 AM, Roedy Green wrote:
> 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/07/java-7-diamond-operator.html
>
> http://mindprod.com/book/9781849685627.html

With some exaggeration one might call it Java's type inferencing...

[toc] | [prev] | [next] | [standalone]

#13368

On 04/04/2012 7:12 AM, Silvio Bierman wrote:
> On 04/04/2012 03:54 AM, Roedy Green wrote:
>> 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".
> With some exaggeration one might call it Java's type inferencing...

Well, maybe, but from the little I recall of my programming language 
design classes, "real" type inferencing is a lot more powerful, so I 
think you ought to have said "much exaggeration."

[toc] | [prev] | [next] | [standalone]

#13369

On 04/04/2012 02:23 PM, David Lamb wrote:
> On 04/04/2012 7:12 AM, Silvio Bierman wrote:
>> On 04/04/2012 03:54 AM, Roedy Green wrote:
>>> 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".
>> With some exaggeration one might call it Java's type inferencing...
>
> Well, maybe, but from the little I recall of my programming language
> design classes, "real" type inferencing is a lot more powerful, so I
> think you ought to have said "much exaggeration."

Yep, it was an understatement.

[toc] | [prev] | [next] | [standalone]

#13401

On 4/4/2012 8:23 AM, David Lamb wrote:
> On 04/04/2012 7:12 AM, Silvio Bierman wrote:
>> On 04/04/2012 03:54 AM, Roedy Green wrote:
>>> 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".
>> With some exaggeration one might call it Java's type inferencing...
>
> Well, maybe, but from the little I recall of my programming language
> design classes, "real" type inferencing is a lot more powerful, so I
> think you ought to have said "much exaggeration."

Give that the JLS says:

<quote>
If the type argument list to the class is empty — the diamond form "<>" 
— the type arguments of the class are inferred.
</quote>

then the usage of "type inference" can be defended.

But it is certainly not what type inference is in languages
like Scala etc..

Arne

[toc] | [prev] | [next] | [standalone]

#13412

On 04/04/2012 7:41 PM, Arne Vajhøj wrote:
> But it is certainly not what type inference is in languages
> like Scala etc..
Let alone Standard ML, where IIRC type inference is NP-hard.

[toc] | [prev] | [next] | [standalone]

#13370

Roedy Green <see_website@mindprod.com.invalid> 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/07/java-7-diamond-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.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#13403

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/07/java-7-diamond-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.

It was added to Java to satisfy the whiners who were afraid they might strain a finger typing "Ctrl-V" or hitting ENTER on the IDE suggestion. Heaven help any of those folks should they ever have to actually work for a living.

Not that I eschew the diamond operator myself now that it's here, but I wasn't clamoring for it beforehand.

-- 
Lew
Diamonds are a girl's best friend. Dogs are a man's best friend. Diamonds cost more at first, but don't require feeding, walking, shots, neutering or spaying, veterinary or funeral bills, housebreaking, orreplacement expenses for broken goods, and don't have litters. Still, I wish I had a dog.

[toc] | [prev] | [next] | [standalone]

#13422

On 04/04/2012 9:15 PM, Lew 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".
>>
>> This isn't wrong, but it fixes a problem I never knew I had.  Any
>> competent IDE will expand that for you anyway.
>
> It was added to Java to satisfy the whiners who were afraid they might strain a finger
 > typing "Ctrl-V" or hitting ENTER on the IDE suggestion. Heaven help 
any of those
 > folks should they ever have to actually work for a living.

Overly harsh IMHO. If you ever change one of those places, you need to 
change them all, and having the language feature makes it easier and 
less error prone.

[toc] | [prev] | [next] | [standalone]

#13424

David Lamb <dalamb@cs.queensu.ca> writes:

> On 04/04/2012 9:15 PM, Lew 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".
>>>
>>> This isn't wrong, but it fixes a problem I never knew I had.  Any
>>> competent IDE will expand that for you anyway.
>>
>> It was added to Java to satisfy the whiners who were afraid they might strain a finger
>> typing "Ctrl-V" or hitting ENTER on the IDE suggestion. Heaven help 
> any of those
>> folks should they ever have to actually work for a living.
>
> Overly harsh IMHO. If you ever change one of those places, you need to
> change them all, and having the language feature makes it easier and
> less error prone.

There may be use cases where this is unequivocally a Good Thing; I've
just never happened to run into one.  Not sure I buy the error prone
part, though: if it isn't correct it won't compile.

I notice there's an Eclipse enhancement request to add a refactoring
method to handle changing generic parameters:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=372568

Seems a bit late at this point.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#13434

On 04/04/2012 06:23 PM, Jim Janney wrote:
> Roedy Green<see_website@mindprod.com.invalid>  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/07/java-7-diamond-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.

[toc] | [prev] | [next] | [standalone]

#13439

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/07/java-7-diamond-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 to judge 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.

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#14310

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

[toc] | [prev] | [next] | [standalone]

#13445

Silvio Bierman <silvio@moc.com> writes:

> On 04/04/2012 06:23 PM, Jim Janney wrote:
>> Roedy Green<see_website@mindprod.com.invalid>  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/07/java-7-diamond-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

[toc] | [prev] | [next] | [standalone]

#13446

Jim Janney <jjanney@shell.xmission.com> writes:

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

Sorry, 1.5 syntax of course.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#13409

W dniu 2012-04-04 03:54, Roedy Green pisze:
> 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/07/java-7-diamond-operator.html
>
> http://mindprod.com/book/9781849685627.html

It will be better to provide "auto" type detector, like in C++.
For example, instead of:
   Map<Integer, List<String>> map = new HashMap<Integer, List<String>>();
use:
   auto map = new HashMap<Integer, List<String>>();

...and "map" variable will be resolved at compile time to 
HashMap<Integer, List<String>>.

This allow very handy construct, like:

   auto data = SomeService.getProviders();

In this case type of "data" will be deducted from return type of 
SomeService.getProviders().

This will save lot of typing. And save refactoring time in case if 
getProviders return type changes. And will auto-adapt to changes in 
libraries.

-- 
Arivald

[toc] | [prev] | [next] | [standalone]

#13420

Arivald wrote:
> It will be better to provide "auto" type detector, like in C++.
> For example, instead of:
>    Map<Integer, List<String>> map = new HashMap<Integer, List<String>>();
> use:
>    auto map = new HashMap<Integer, List<String>>();
> 
> ...and "map" variable will be resolved at compile time to 
> HashMap<Integer, List<String>>.
> 
> This allow very handy construct, like:
> 
>    auto data = SomeService.getProviders();

If 'auto' is a type, it should begin with an upper-case letter. If it's not, you should explain what you intend.

> In this case type of "data" will be deducted [sic] from return type of 
> SomeService.getProviders().
> 
> This will save lot of typing. And save refactoring time in case if 

It will save virtually no typing compared to current Java idioms.

> getProviders return type changes. And will auto-adapt to changes in 
> libraries.

This idea is incompatible with the current direction of type inference, which is in the other direction, and with Java's strong typing philosophy, and apparently the Powers That Be disagreed that your idea is better, as they didn't implement it.

Your suggestion:
> auto map = new HashMap<Integer, List<String>>();
 
Current idiom:

  Map<Integer, List<String>> map = new HashMap<>();

Not much difference in typing, certainly not enough to get your knickers in a twist over.

Your suggestion:
> auto data = SomeService.getProviders();
which you describe as "very handy", but violates strong typing, which requires that the compiler know the type of 'data'. If the (presumably static) method you describe were to change its return type, it would break the client code that relies on knowledge of the type of 'data'.

The current inference direction is that the generics of a method declaration are resolved by the invocation context, when possible:

  Map<Integer, List<String>> data = getProviders();

where the declaration of the method is something like:

  public Map<T, U> getProviders();

Type inference tells 'getProviders()' what types 'T' and 'U' are.

Your suggestion would break those.

So it won't happen for those big reasons.

You should understand that changes to the Java language must meet at least two criteria, irrespective of whether they even provide value (which I don't see that yours does):

 - they must not break Java (which yours does), at least not too much,
 - they must provide enough value to justify making any change at all (which yours doesn't).

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#13423

W dniu 2012-04-05 20:34, Lew pisze:
> Arivald wrote:
>> >  It will be better to provide "auto" type detector, like in C++.
>> >  For example, instead of:
>> >      Map<Integer, List<String>>  map = new HashMap<Integer, List<String>>();
>> >  use:
>> >      auto map = new HashMap<Integer, List<String>>();
>> >
>> >  ...and "map" variable will be resolved at compile time to
>> >  HashMap<Integer, List<String>>.
>> >
>> >  This allow very handy construct, like:
>> >
>> >      auto data = SomeService.getProviders();
> If 'auto' is a type, it should begin with an upper-case letter. If it's not, you should explain what you intend.

"auto" is (in C++) reserved word, part of language. It is resolved to 
concrete type at compile time, to type of first assigned value.


>> >  In this case type of "data" will be deducted [sic] from return type of
>> >  SomeService.getProviders().
>> >
>> >  This will save lot of typing. And save refactoring time in case if
> It will save virtually no typing compared to current Java idioms.
>
>> >  getProviders return type changes. And will auto-adapt to changes in
>> >  libraries.
> This idea is incompatible with the current direction of type inference, which is in the other direction, and with Java's strong typing philosophy,

"auto" in C++ is strongly typed, at compile time.


> and apparently the Powers That Be disagreed that your idea is better, as they didn't implement it.
>
> Your suggestion:
>> >  auto map = new HashMap<Integer, List<String>>();
>
> Current idiom:
>
>    Map<Integer, List<String>>  map = new HashMap<>();

Current now... but apparently it is something new in Java 7. Till Java 7 
there was lot of redundant typing.

Yet "diamond operator" does not allow to deduct type of variable from 
assigned function return value;


> Not much difference in typing, certainly not enough to get your knickers in a twist over.
>
> Your suggestion:
>> >  auto data = SomeService.getProviders();
> which you describe as "very handy", but violates strong typing,

Again no, there is no typing violation. "auto" does not mean "any type", 
it mean "compiler, be nice and use type of first assigned variable". It 
is just syntactic sugar.


 > which requires that the compiler know the type of 'data'.

No. Compiler know type returned by SomeService.getProviders(). And will 
use this type instead.

Assuming that SomeService.getProviders() declare to return List<String>, 
this code:

   auto data = SomeService.getProviders();

and this code:

   List<String> data = SomeService.getProviders();

have same meaning. Both describe variable named "data" with type 
"List<String>".

Note that compiler take type that function declare to return, not type 
of really returned object!


>If the (presumably static) method you describe were to change its return type, it would break the client code that relies on knowledge of the type of 'data'.

If this method change its return type, code must be recompiled anyway, 
both with and without "auto". Currently Your code will stop compiling if 
new return type is incompatible with declared variable type.
With "auto", compiler will adapt, and try compile subsequent source code 
with new type.

>
> The current inference direction is that the generics of a method declaration are resolved by the invocation context, when possible:
>
>    Map<Integer, List<String>>  data = getProviders();
>
> where the declaration of the method is something like:
>
>    public Map<T, U>  getProviders();
 >
> Type inference tells 'getProviders()' what types 'T' and 'U' are.

Interesting idea, I do not know that.

But what You can do with this inferred types 'T' and 'U' in 
getProviders()? With Java generics not much. On the contrary to C++ 
templates, You can not use T and U beyond Object type capabilities.
Only Java reflection can save this construct, and make it a bit more useful.

>
> Your suggestion would break those.

Not really. In this case compiler could issue error, due to not enough 
information. In this case programmer will be not allowed to use "auto".

> So it won't happen for those big reasons.
>
> You should understand that changes to the Java language must meet at least two criteria, irrespective of whether they even provide value (which I don't see that yours does):
>
>   - they must not break Java (which yours does), at least not too much,

I think there is no break. Type is exactly known at compile time, and 
will generate same bytecode.

>   - they must provide enough value to justify making any change at all (which yours doesn't).

I respect Your opinion, but disagree. I found "auto" keyword very useful 
in C++. This is one of features I really miss in Java.

By the way, I also miss few other things, like "typedef" keyword (for 
type aliasing) or templates. Both are great helpers for meta-programming.
Java have "generics", which appears like C++ templates. But only 
appears, at first glance. Generics are no real templates, they just 
syntactic sugar that hide casting and allow a bit better compile time 
type checking. Nothing compared to real templates from C++. Very 
disappointing.
Not mentioning security problems with Java generics...

-- 
Arivald

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web