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

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

Re: diamond operator

Show all headers | View raw

On 4/5/2012 1:34 PM, Lew wrote:
> 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.

The `auto' comes from C++11, where the type of the variable is defined 
to be the type of the static value being assigned to it [1]. It is a lot 
more powerful in C++, where the language can define some obscene, opaque 
hidden types whose exact signatures are left unspecified by the 
specification. The largest set of these are the STL iterators, where 
iterators look like `std::map<A, B>::iterator', but, when expanded, tend 
to be a class with five or six template parameters and a name with way 
too many underscores to be sane. The following all refer to the same type:
std::map<A, B>::iterator
std::_Rb_tree<A, std::pair<A, B>, std::_Select1st<std::pair<A, B> >, 
std::less<A>, std::allocator<std::pair<const A, B> > >::iterator
std::_Rb_tree_iterator<std::pair<A, B> >

Given that A and B can be very long types themselves, it quickly becomes 
obscene just to write a simple for each loop, although C++11 also 
introduces a version of for-each loops that ameliorate this.

The other reason for auto is lambda expressions: the type of a lambda 
expression is "a unique, unnamed class that has the following 
properties", much as the actual type of an anonymous inner class in Java 
is a unique, unnamed class which is only guaranteed to inherit from some 
method.

> 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.

The C++11 auto keyword is still fully strongly typed. It's meaning is 
best described is "the compiler already knows the precise type of this 
variable, and I know what I can do with this type, but I don't want to 
spend 15 minutes fighting the compiler to figure out what the right type 
actually is." In C++, because of the magic of templates and typedefs, 
you can actually spend several minutes just trying to figure out how to 
tell the compiler the proper name of a type.

In short, auto is not a matter of dynamic versus static typing, it's a 
matter of implicit versus explicit typing. C++ has a fairly complex type 
system that has lots of edge cases which happen surprisingly often, 
while Java's type system is cleaner, even if you throw in generics. 
Given also that I suspect templates are much more abused than Java's 
generics, I don't think the auto is as useful in Java as it is in C++.

[1] If you really want to play language lawyer, it's the same type for 
the initializer expression as would be derived for template argument 
inference.

-- 
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

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