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

Data Classes for Java

cr.openjdk.java.net

Post reply on HN
Print view View original

11–20 of 216 posts

Re: Data Classes for Java

#11

Post by opmac »

iamandoni wrote: post #4
HumanDrivenDev wrote: post #2

... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…

While I mostly agree, getters without setters is a nice way to expose that youre data is immutable rather than relying on final fields

Just use public final. That is the defacto way to make immutable data classes. Why would a data class need non final fields?

Re: Data Classes for Java

#12

Post by virmundi »

HumanDrivenDev wrote: post #2

... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…

In Java, they came with the bean standard. The goal was to codify properties to make reflection easier. That’s it.

If you don’t need reflection or the bean utilities that help with that, just use simple public final T values.

Re: Data Classes for Java

#13

Post by mohaine »

HumanDrivenDev wrote: post #2

... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…

Getters/Setters do have a couple of reasons to exist:

1) Allowing you to validate data/morph data on your objects on set. (example: Date is not a workday)

2) Allow others to do either 1 or other actions on set/get (examples: Hibernate entity beans that update db/set dirty on set, GUI can extend object to update on set)

That said it was a total PITA when this first became popular. I spent way too much time changing code over because that was now "best practice". And don't get me started on Boolean not being get but is or has.

Re: Data Classes for Java

#14

Post by drizze »

HumanDrivenDev wrote: post #2

... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…

To provide flexibility in the future. When your data comes from a method you can change its source without changing the caller. This can be very useful and should be leveraged whenever possible.

Re: Data Classes for Java

#15

Post by pjmlp »

sushisource wrote: post #7
harryh wrote: post #3

I, for one, am enjoying the ever so slow scalaization of java.

If the JVM magically got rid of nulls and Scala cleaned up some of the slightly wartier bits (implicits come to mind, although they are useful and no clue how I'd fix em...) then Scala would be my favorite language around by quite a bit. Besides maybe Rust. Really different usecases though.

Slow and steady, we don't want to have a Python 3.

When minimal value types get implemented, there will be a way to slowly fix those issues.

Likewise with the ongoing work with Dotty.

Re: Data Classes for Java

#16

Post by bunderbunder »

HumanDrivenDev wrote: post #2

... To write such a class responsibly, one has to write a lot of low-value, repetitive code: constructors, accessors ... If you're writing a plain data class, why on earth would you write getters and setters? Just make your fields public and be done with it. I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar). I have no idea what problem they solve. If you're at the l…

I can't speak to Java, but in C#, the original goal was to reduce coupling. You can add behavior to getter and setter methods without breaking binary compatibility among packages. It absolutely is obfuscation, to the extent that encapsulation is just a special kind of obfuscation.

Possibly more importantly, public fields give you no way to create immutable types.

Re: Data Classes for Java

#17

Post by bunderbunder »

sushisource wrote: post #7
harryh wrote: post #3

I, for one, am enjoying the ever so slow scalaization of java.

If the JVM magically got rid of nulls and Scala cleaned up some of the slightly wartier bits (implicits come to mind, although they are useful and no clue how I'd fix em...) then Scala would be my favorite language around by quite a bit. Besides maybe Rust. Really different usecases though.

I don't think many of Scala's wartier bits will go away without Java getting its act together re: things like type erasure and a bifurcated type system, because a lot of the odder things in Scala are basically workarounds for deficiencies in the underlying platform. And I just don't see much political momentum behind either of those.

Re: Data Classes for Java

#19

Post by Cyph0n »

sushisource wrote: post #7
harryh wrote: post #3

I, for one, am enjoying the ever so slow scalaization of java.

If the JVM magically got rid of nulls and Scala cleaned up some of the slightly wartier bits (implicits come to mind, although they are useful and no clue how I'd fix em...) then Scala would be my favorite language around by quite a bit. Besides maybe Rust. Really different usecases though.

Dotty, Scala Native, and Scala.js are all interesting projects that may just end up improving Scala in the long run. I actually love Scala as it is, so I can't imagine how great it will become when the compile times improve and the warts are cleaned up.

Re: Data Classes for Java

#20

Post by cageface »

sushisource wrote: post #7
harryh wrote: post #3

I, for one, am enjoying the ever so slow scalaization of java.

If the JVM magically got rid of nulls and Scala cleaned up some of the slightly wartier bits (implicits come to mind, although they are useful and no clue how I'd fix em...) then Scala would be my favorite language around by quite a bit. Besides maybe Rust. Really different usecases though.

Kotlin is a great middle ground IMO. It has a lot of the expressive power of Scala but is a much simpler language.
Post reply on HN