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


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

Re: diamond operator

From Lew <lewbloch@gmail.com>
Newsgroups comp.lang.java.programmer
Subject Re: diamond operator
Date 2012-04-05 11:34 -0700
Organization http://groups.google.com
Message-ID <8404504.2717.1333650899408.JavaMail.geo-discussion-forums@pbrx1> (permalink)
References <n4ann71plharl1ank5424uvqdi2ffpfh67@4ax.com> <jljk7j$6be$1@news.dialog.net.pl>

Show all headers | View raw


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

Back to comp.lang.java.programmer | Previous | NextPrevious 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