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

Java 9 features announced

jaxenter.com

Post reply on HN
Print view View original

181–190 of 228 posts

Re: Java 9 features announced

#181

Post by virtualwhys »

vishbar wrote: post #177
wyager wrote: post #101

Earlier quoted context omitted.

Not exactly comparable (because everything is immutable), but Haskell has sort of a cool approach to setting and getting fields. Let's say you have data Point = Point {x :: Int, y :: Int} If you have a Point object called "point", you can get x by doing x_coord = x point If you want to create a new Point with x set to 5, you can do point' = point {x = 5}

F# has a similar concept via the with statement. To use your example: type point = { x: int; y:int} let z = {x = 5; y = 10} let y = {z with x = 17}

Interesting, Scala equivalent is:

    case class Point(x: Int, y: Int)
    val p1 = Point(5,10)
    val p2 = p1.copy(x=17)
How does F# handle nested data types? In Scala if you want to copy a case class of a case class (of a case class ...) it can get boilerplate-y as you have to copy outside-in through each property a la:

    x.copy(acase.copy(bcase.copy(cprop=1)))

Re: Java 9 features announced

#182

Post by illumen »

bcj wrote: post #160
adevine wrote: post #129

Earlier quoted context omitted.

I disagree. A fundamental, language-level problem with Java is that clients need to know when they are accessing a member var, e.g. obj.foo, vs. calling a method, e.g. obj.foo(). This means that its much safer to always wrap things in a method, because if you ever need to change something (or do things like add logging, delegation, or some other filtering behavior), you can do it behind your method without clients ne…

Python has a solution to this. There are decorators that allow you to access methods as if they are properties: class Foo(object): def __init__(self, bar): self._bar = bar @property def bar(self): return self._bar @bar.setter def bar(self, value): self._bar = value

As does Objective-C, and JavaScript.

Re: Java 9 features announced

#183

Post by eneveu »

rufugee wrote: post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

I'd use immutable value classes with AutoValue: https://github.com/google/auto/tree/master/value . It's developed by the googlers behind the awesome Guava library.

Re: Java 9 features announced

#184

Post by vetler »

stevebot wrote: post #110
ryanobjc wrote: post #97

Earlier quoted context omitted.

It is addressed by better design. First off, it's important to know the difference between value types and objects. For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that. Objects encapsulate mutable state, and getFoo…

I agree and I hate getters, but I am one of those who still hasn't figure out how to do OOP correctly. Do you have an example or maybe some suggested reading? For example, if I have a user object, with name, age, number, how would that work without get/set? I'd love to avoid it, I hate the bloat it creates, and also how frivolous it seems to test get/set.

Here's a tip: instead of changing your objects, you can create a new object with the same values except the ones you want to change.

Another option is to use builders (that are mutable), to build/copy your immutable business (?) objects.

Re: Java 9 features announced

#186

Post by mhaymo »

pjmlp wrote: post #70
adamlett wrote: post #19

Still no hash literal :-(

There is a JEP for alleviating the problem. http://openjdk.java.net/jeps/8048330

And that JEP basically already exists in Guava https://code.google.com/p/guava-libraries/wiki/ImmutableColl...

`ImmutableList.of("a", "b", "c")` is not as concise as e.g. Python, but it's not bad.

Re: Java 9 features announced

#187

Post by pjmlp »

ryanobjc wrote: post #97
rufugee wrote: post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

It is addressed by better design. First off, it's important to know the difference between value types and objects. For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that. Objects encapsulate mutable state, and getFoo…

> The big issue is that a lot of java was created when we still hadn't figured out how to properly do Object Oriented Programming.

Bollocks, there were already plenty of OO languages when Java appeared on the block.

Re: Java 9 features announced

#188

Post by haddr »

einrealist wrote: post #84
haddr wrote: post #5

I'm deeply missing hot swapping. I believed it could be included in java 9 but i think we have to wait...

What is wrong with restarting your application? Edit: Real Hotswapping will requires profound changes to the memory model. It would introduce too much complexity. I rather restart my application than to suffer from a fragile and leaking platform.

of course you can restart your app, but it's not sufficient answer to the problem. Apparently long time ago hot swapping was scheduled around Java 9, but they didn't progress with it since then. See JEP-159 for more details: http://openjdk.java.net/jeps/159

Re: Java 9 features announced

#189

Post by sltkr »

pjmlp wrote: post #187
ryanobjc wrote: post #97

Earlier quoted context omitted.

It is addressed by better design. First off, it's important to know the difference between value types and objects. For a value type, public final fields are good. They are set in the constructor once, and can only be read, and can't change. Getters are pointless, and my code does not have them. If you want them for a reason, then intellij does an amazing job fixing that. Objects encapsulate mutable state, and getFoo…

> The big issue is that a lot of java was created when we still hadn't figured out how to properly do Object Oriented Programming. Bollocks, there were already plenty of OO languages when Java appeared on the block.

Sure, but more radicial OO languages like Smalltalk were full of getters/setters too (e.g. in Smalltalk all member variables are private, so getters/setters are the only way to access those) so it makes sense to think that this was just the way to go.

Re: Java 9 features announced

#190

Post by mercurial »

vetler wrote: post #184
stevebot wrote: post #110

Earlier quoted context omitted.

I agree and I hate getters, but I am one of those who still hasn't figure out how to do OOP correctly. Do you have an example or maybe some suggested reading? For example, if I have a user object, with name, age, number, how would that work without get/set? I'd love to avoid it, I hate the bloat it creates, and also how frivolous it seems to test get/set.

Here's a tip: instead of changing your objects, you can create a new object with the same values except the ones you want to change. Another option is to use builders (that are mutable), to build/copy your immutable business (?) objects.

That's what we do at work. Then when work is done, I look at OCaml and repeat the mantra "I'm not going to think about how many lines it takes in Java to do a functional update 'let foo2 = { foo1 with foo_field = "bar" }'".

It is possible to have immutable objects in Java and have the equivalent of functional updates, but it's a hell of a lot of pointless boilerplate. It still beats traditional Java beans, though.

Post reply on HN