Hacker News Reader

Comment by vivin | Hacker News Reader

This is pretty nice. Hope it goes through. It's about time that we had local-variable inference in Java. It does mean that the diamond can't be used this way:

  var list = new ArrayList<>();

There is no way to infer the type of the generic parameter. So we will go back to doing:

  var list = new ArrayList<String>();

Which isn't a big deal IMO because the generic parameters had to be specified on the LHS anyway to use the diamond. You also end up using fewer characters in general with var even without being able to use the diamond.

Regarding val vs let, I prefer let simply because it's harder to accidentally type let vs typing var instead of val (or vice versa).

View on HN

> Regarding val vs let

I like the approach mentioned of just reusing final for immutability.

Making the immutable version the same length as (or preferably, shorter than, e.g. Rust) the mutable version encourages the use of immutability.

val is a much better idea. Final is longer to type, in many cases as long as just declaring the type. We should be encouraging immutability not discouraging it by making it more verbose than necessary.

As far as val vs let goes, I actually prefer val, because it has symmetry with var. That is to say "variable foo" is more similar to "value foo" than "let foo," since "value" is an adjective like "variable". Of course, I suppose this is personal preference.

there is but I don't know if it can be retrofitted onto java.

In rust and haskell, ect. types can be worked out backwards so that the type is figure out with use.

    fn main() {
        let mut v = Vec::new();
        v.push("hello");
        v.push("world!");
        println!("output: {:?}", v.join(" "));
    }

the type of v is `Vec<&str>` worked out backwards from where &str literal is added(since the type of push is fn `push(&mut self, value: T)` the T generic of Vec<T> must be &str).

I've been doing List<String> list = new ArrayList<>();

Isn't that good enough?

For your example, it makes no difference. However, take a look at the other example mentioned at the beginning:

    var stream = list.stream();   // infers Stream<String>

How would you write it in order to take advantage of type inference?

No.

The List<String> is almost as redundant as the RHS <String> was.

I hope this gets rejected. The given examples are too ideal as they are all using familiar Java standard APIs. I doubt if it's a good idea in practice since you can end up with unreadable code when integrating with third party APIs.

> I doubt if it's a good idea in practice since you can end up with unreadable code when integrating with third party APIs.

This works perfectly fine in practice as can be seen using comparable constructs in C#, C++, and many other mainstream languages.

If anything it's more readable, since your code isn't littered with redundant type info.

> If anything it's more readable, since your code isn't littered with redundant type info.

I fail to see the redundant type info.

Example 1:

int maxWeight = blocks.stream() .filter(b -> b.getColor() == BLUE) .mapToInt(Block::getWeight) .max();

"int" is not redundant type info here.

Example 2:

List<String> list = new ArrayList<>(); // (1)

var list = new ArrayList<String>(); // (2)

Many would say List<String> in (1) is redundant but I would argue otherwise. The intention of List<String> in (1) is to reference to the underline ArrayList through List interface. (1) is trying to encourage programming to an interface while (2) just completely destroys the practice by inferring the type for list variable to be ArrayList<String>. That means subsequent method invocations after (2) can be methods from ArrayList not List.

If you can explain the value of restricting a local initialized with a new instance being inferred to be an interface type, you'll have a point. You won't be able to, because there is literally no point since the constructor must be statically referenced anyway, but I'd love to see you try.

Have you never Map<Shard, ListenableFuture<RpcEndpointResult>>? And then mapped it through various asynchronous transformations? Good god, the type soup.

There is a point where typing becomes verbose and decreases readability. If the compiler can infer, it should. It'll save time, money, and sanity.

You fail to see that type inference is optional. So yes for readability's sake, in your first example I wouldn't omit the "int", but in simpler cases you CAN omit if you want. And that's just nice, end of story.

Optional, alright, but promoting bad practices. If people like dumb-down languages, there are plenty of them already!

What are the bad practices being promoted by this? How does it qualify as dumbed down? Simply ranting about things that, charitably, you don't seem to understand, does not make the rants valid.

As the sibling comment indicates, and I wish to amplify with precision, if you are using the static constructor reference to initialize the local, declaring the local reference to be of a super type is cargo cult nonsense, not a best practice. The concrete type is already locally known, nothing is gained via the abstraction.

The best practice is that the type of the variable is of the interface, not the implementation except in some special cases.

So stop using constructors and start using static factory methods. The return type of a static factory method can be the interface type.

Yeah, let's UML the hell out of everything to be enterprisey and be Martin Fowler-approved! This is what turned off a lot of people before!

Sorry, did "static factory" sound scary? How about "use a function to create your objects" instead?

So instead of doing this:

    Foo foo = new Foo("bar");

You can do this:

    Foo foo = Foo.of("bar");

Yeah, but how about the implementation?

This is complete nonsense if you're using a static constructor and not a factory. There's zero point to doing this for a local, statically constructed type. It's not a best practice.

If you were using a factory, var would infer the factory signature's type, which would normally be the interface.

No, it's not a complete nonsense, no. People abusing Java with overengineering and using factories and other enterprisey design patterns for everything made a lot of people leave the Java land!

> People abusing Java with overengineering and using factories and other enterprisey design patterns for everything made a lot of people leave the Java land!

Actually, people left Java land because they couldn't express what they needed to without using complicated design patterns.

A "static factory" is just a static method. You know, a function. Nothing over-engineered or enterprisey about using functions to allocate objects.

Why state the obvious?

> Why state the obvious?

So you think using functions is enterprisey and over-engineering things?

Read my other reply to you on the subject! The API might be a small syntactic change, but the concepts and the implementation behind those for noobs are not. They learn OOP and constructors and then you tell them - they suck, use factories via static methods.

Yes, but that's a fault in Java the language. Keeping Java bad doesn't solve that problem.

I agree. A little native support for wide-spread best practices would only be a good thing for Java.

I agree. "var" as proposed is dumbing down Java. If there's an intelligent way to infer the interface, not the implementation, then I'd accept it, but otherwise, it's the JavaScriptification if Java given most IDEs can autocomplete this and let you correct if they assume wrongly.

Reply on news.ycombinator.com