Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JEP 286: Local-Variable Type Inference

openjdk.java.net

Post reply on HN
Print view View original

121–130 of 132 posts

Re: JEP 286: Local-Variable Type Inference

#121

Post by plesner »

wvenable wrote: post #32
plesner wrote: post #23

In their list of risks there's one missing: it makes changing the return type of a method to a subclass a subtly breaking change. Say some api defines a method, Collection getNames() { ... } and in your code you do var names = getNames(); if (...) names = Collections.emptySet(); Now, if the api later changes getNames() to be List getNames() { ... } your code breaks. That's one of the advantages of only allowing this…

I think in practice this would be pretty rare. At least coming from a C# background it doesn't seem to be an issue I've ever encountered.

It's possible that it's more a theoretical than a practical problem, I would hope so. But it does seem to me like fundamentally a problematic property of a type system that having more accurate types can break your program. It's the static type equivalent of breaking the Liskov substitution principle.

Re: JEP 286: Local-Variable Type Inference

#122

Post by rat87 »

vivin wrote: post #6

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 (); Which isn't a big deal IMO because the generic parameters had to be specified on the LHS anyway to use the diamond…

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` 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 must be &str).

Re: JEP 286: Local-Variable Type Inference

#123

Post by wvenable »

plesner wrote: post #121
wvenable wrote: post #32

Earlier quoted context omitted.

I think in practice this would be pretty rare. At least coming from a C# background it doesn't seem to be an issue I've ever encountered.

It's possible that it's more a theoretical than a practical problem, I would hope so. But it does seem to me like fundamentally a problematic property of a type system that having more accurate types can break your program. It's the static type equivalent of breaking the Liskov substitution principle.

If a library author makes such a fundamental change their public API by making a method return more specific, I might actually want to know about it. I don't find it particularly problematic since it seems like code smell for that sort of change to happen in the first place.

Re: JEP 286: Local-Variable Type Inference

#124

Post by wtetzner »

nikolay wrote: post #119
wtetzner wrote: post #107

Earlier quoted context omitted.

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");

Re: JEP 286: Local-Variable Type Inference

#125

Post by wtetzner »

nikolay wrote: post #118
msbarnett wrote: post #113

Earlier quoted context omitted.

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!

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

Re: JEP 286: Local-Variable Type Inference

#126

Post by nikolay »

wtetzner wrote: post #125
nikolay wrote: post #118

Earlier quoted context omitted.

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!

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?

Re: JEP 286: Local-Variable Type Inference

#127

Post by nikolay »

wtetzner wrote: post #124
nikolay wrote: post #119

Earlier quoted context omitted.

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?

Re: JEP 286: Local-Variable Type Inference

#128

Post by wtetzner »

nikolay wrote: post #126
wtetzner wrote: post #125

Earlier quoted context omitted.

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?

Re: JEP 286: Local-Variable Type Inference

#129

Post by wtetzner »

nikolay wrote: post #118
msbarnett wrote: post #113

Earlier quoted context omitted.

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.

Re: JEP 286: Local-Variable Type Inference

#130

Post by nikolay »

wtetzner wrote: post #128
nikolay wrote: post #126

Earlier quoted context omitted.

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.
Post reply on HN