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

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

Re: diamond operator

Show all headers | View raw

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

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