Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #13420
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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