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

171–180 of 216 posts

Re: Data Classes for Java

#171

Post by BlackFly »

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…

Short answer: to avoid side effects from other parts of the code rippling into the data class.

Some objects are inherently mutable and exposing a reference to them allows mutability. You might not have control of all the class definitions in your data domain in order to make them immutable. Instead, a getter and setter can create equal copies and return those.

This is assuming you are talking about getters and setters on immutable objects. If you are talking about mutable objects, then they really need getters and setters to ensure that mutations on the object they return or receive do not affect them.

Re: Data Classes for Java

#172

Post by zmmmmm »

vaskebjorn wrote: post #29
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 my experience writing getters and setters has been boilerplate 99% of the time. But I still write them because situations arise where you do need to change the nature of that property, sometimes dynamically, and then it's suddenly worth it. You can, for instance, change a getter and none of the class's clients need to know or care about the change. Though I haven't used Groovy much I like their approach to this: "…

> Though I haven't used Groovy much I like their approach to this

I like this a lot about Groovy as well. Groovy also provides annotations that relieve a lot of the other points too, such as @Immutable [1], @EqualsAndHashcode [2] and @ToString. It even supports meta-annotations which let you alias several annotations together as one so you can make a complete "data class" with a single annotation.

[1] http://docs.groovy-lang.org/latest/html/gapi/groovy/transfor...

[2] http://docs.groovy-lang.org/latest/html/gapi/groovy/transfor...

Re: Data Classes for Java

#173

Post by js8 »

sitkack wrote: post #90
mbell wrote: post #57

Earlier quoted context omitted.

Design patterns are bug reports against your programming language. -- Peter Norvig Java sure has a lot of patterns.

Appeal to authority. Show me a language with little to no patterns.

I don't think there is a language without patterns. But in other programming languages (Lisp, Haskell), we just call them functions.

Edit: Actually, I think your request is even more ridiculous. If what Norvig is saying is true, then every language has patterns, because every language has bugs. So you are asking to substantiate his statement by providing a counterexample.

Re: Data Classes for Java

#174

Post by merb »

qw wrote: post #148
FollowSteph3 wrote: post #118

Earlier quoted context omitted.

Let me give a concrete example from my past. We had a public API of POJO domain objects that could be used to render templated files, think string replace. It worked great until one day someone had a special character that caused it all to fail. How do you fix this? Ask all customers to clean their values? Good luck with that!! However from our side we just added the code to clean the output, escape the special chara…

What use did you have from the getter? That seems like a situation where you would only change the setter (or a builder if you use that pattern).

or the constructor..

Re: Data Classes for Java

#175

Post by willtim »

lmm wrote: post #165
willtim wrote: post #157

Earlier quoted context omitted.

Why would type erasure affect the front end language? I'm generally interested.

One of the earliest use cases for implicits is that in Java most types are erased but Arrays aren't, so you can't instantiate an Array in a generic method without having some way to pass the concrete type through.

I do not see why this problem cannot be solved by a compiler rather than a language feature. The type is statically known. It may require additional metadata alongside class files for separate compilation, but I don't see this as a big issue.

Re: Data Classes for Java

#176

Post by lmm »

willtim wrote: post #175
lmm wrote: post #165

Earlier quoted context omitted.

One of the earliest use cases for implicits is that in Java most types are erased but Arrays aren't, so you can't instantiate an Array in a generic method without having some way to pass the concrete type through.

I do not see why this problem cannot be solved by a compiler rather than a language feature. The type is statically known. It may require additional metadata alongside class files for separate compilation, but I don't see this as a big issue.

The type within a generic method can't be statically known. Consider a generic library method that creates an array somewhere deep in its internals, and is called from an application compiled separately.

Now of course you can say that library method requires some extra information from its caller - but how do you reflect that in the method signature in such a way that the binary compatibility constraints are clear and it remains intelligible what the signature is when invoking that method from Java?

Re: Data Classes for Java

#177

Post by cultvoid »

jt2190 wrote: post #46
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…

The pattern evolved from early Java’s lack of reflection. In order to give tools the ability to set/get data, we got the JavaBean. The culture internalized the pattern, and we’ve been mindlessly doing it ever since.

This is correct. JavaBeans were a bad solution to a problem. It was Swing (or was it AWT then?) that needed it first, so that tool builders could allow widgets to have their properties customised. So the vile JavaBean conventions took hold.

I only quibble on the "mindlessly" part. I will never add a get/set in a class if it isn't needed. But invariably, in a Java project, some library somewhere insists that I have them. So eventually I find I've reluctantly added them.

Sometimes you can get away with leaving them private, sometimes not. It's a pain in the neck and like many things in Java, it should have been sorted out years ago.

Re: Data Classes for Java

#178

Post by cultvoid »

aryehof wrote: post #130
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…

Frameworks elevated the need for getters and setters, given the need to programmatically access the internals of objects. Their overuse is also a consequence of the popularity of a programming style of code acting on data, typically within an application that has class data merely representing database entities, acted on by separate logic and constraints in an application/service layer. Behavior based object design s…

Exactly this. If you're working on a system with any need of serialization (eg to/from JSon), or presentation on some kind of view tier, or storage in a database, then the frameworks make get/set pairs inevitable, even if you fight tooth and nail not to have them.

(Of course you could avoid the frameworks, but try telling your project managers that).

Behavior based object design, as well as being an endangered species, probably never existed very much in the first place.

I wonder if Java's popularity was partly due to people being able to appear to do OO whilst actually implementing "code acting on data" systems. You got the warm OO glow without the hard work of doing any behavior driven design.

Re: Data Classes for Java

#179

Post by willtim »

lmm wrote: post #176
willtim wrote: post #175

Earlier quoted context omitted.

I do not see why this problem cannot be solved by a compiler rather than a language feature. The type is statically known. It may require additional metadata alongside class files for separate compilation, but I don't see this as a big issue.

The type within a generic method can't be statically known. Consider a generic library method that creates an array somewhere deep in its internals, and is called from an application compiled separately. Now of course you can say that library method requires some extra information from its caller - but how do you reflect that in the method signature in such a way that the binary compatibility constraints are clear an…

If it creates a specialised concrete array at runtime, then it can't be a truly "generic" method (whereby I assume generic here means parametric polymorphism?). If you want to specialise object arrays to primitive arrays for efficiency, then I do not see why this cannot be a compiler optimization, since the types are statically known at the use sites.

Perhaps Java interoperability is the reason for the choices Scala made, but it doesn't appear that e.g. Scala collections can be used from Java?

Re: Data Classes for Java

#180

Post by taway_1212 »

unscaled wrote: post #160
sitkack wrote: post #90

Earlier quoted context omitted.

Appeal to authority. Show me a language with little to no patterns.

Then what are the design patterns for Scala?

1. Cake pattern (now considered more of an antipattern I think).

2. Extending existing class with implicit conversion.

Post reply on HN