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

151–160 of 216 posts

Re: Data Classes for Java

#151

Post by pjmlp »

dboreham wrote: post #59
jt2190 wrote: post #46

Earlier quoted context omitted.

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.

Appreciate you posting the actual history. One thing I've noticed more and more over the years is this tendency for folks to do things that under analysis make no sense and have no benefit. Even worse, I have a bad feeling that 20 years ago I was one of those people...

You this a lot with C and C with Classes devs, micro-optimizing every single line of code as they write them, based on urban myths or past legends without touching a profiler a single time.

Re: Data Classes for Java

#152

Post by mustardo »

camus2 wrote: post #91
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…

> 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. When doing pure OOP, objects should only communicate via methods, period, it's called state encapsulation and is one of the core principle of OOP, the second being polymorphism. > I will be forever perplexed by the idea of getters and setters (and this extends to C#s syntax sugar…

For arguments sake you could say foo.bar = "baz" syntactic suggar for setBar("baz") sure you now cant add logic to the set method without introducing a real setBar method (and therefore breaking your public interface) but for immutable final DTO / POD style classes that don't have setters just use a public final field and be done with it

There's a difference between understanding encapsulation and being pragmatic

Re: Data Classes for Java

#154

Post by deepsun »

ben-schaaf wrote: post #144
deepsun wrote: post #34

"data class" is already in Kotlin flavor. Yes, I refuse to call Kotlin a different programming language like Scala, because it's just syntactic sugar over good-ol-Java, while all tools, approaches, stackoverflow are the same. But it has the data classes, implemented just like the article described.

Have you actually used kotlin before? It most certainly has features that are much more than just syntactic sugar.

Yes, I use it every day and absolutely love it. Especially the part that it's still syntactic sugar over Java.

Re: Data Classes for Java

#155

Post by usrusr »

wvenable wrote: post #132
HumanDrivenDev wrote: post #115

Earlier quoted context omitted.

I guess I'd call it "changeLastName". That's closer to the domain, we don't go to the Department of Births, Deaths and Marriage and tell the clerk we want to "set" our last name. But that is being too pedantic, even for me. I'll concede defeat. That is a pretty good example. At the end of the day, "customer details" class is actually a big bag of fields that needs some access control and validation.

If you get married, you might "changeLastName" or maybe even "rename" yourself but if you're just moving that name from one place to another you'd "set" it. You could probably come up with lots of different names but none of them will be more clear than "set" in this case.

If moving requires a name to be set you are at constructor time, no need for permanently available setters.

Re: Data Classes for Java

#157

Post by willtim »

bunderbunder wrote: post #17
sushisource wrote: post #7

Earlier quoted context omitted.

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.

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

Re: Data Classes for Java

#158

Post by dtech »

grok2 wrote: post #85
millstone wrote: post #76

Earlier quoted context omitted.

Today's fields are tomorrow's computed properties. Fields are rigid and cannot be changed without recompiling dependencies. Notice how few fields there are in Java's standard library. Why have fields at all?

How many times have you run into this in your career (the need to convert "today's fields to tomorrow's computer properties")?

Quite often, especially if you make a variation of an existing class (or an extra type in an ADT).

Scala does this quite transparent. Something defined as a `var` (variable), `val` (immutable variable), `lazy val` (lazy immutable variable) or `def` (method) is called source- and binary compatible from the caller side.

I've never seen this trick anyone, except for maybe unexpected bad performance.

Re: Data Classes for Java

#159

Post by alkonaut »

flukus wrote: post #9
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…

You'll get you run out of town with that level of heresy in most java/c# shops. Getters and Setters are great when you want finer control over what can access certain fields, in a List class for instance, I wouldn't want the length to be externally writable. But somewhere along the way it went from a useful feature in some circumstances to a mandatory feature in all circumstances. In the c# world "public int Id;" wil…

"public int Id" should fail the code review, but "public readonly int Id" should not...

public readonly int Id is perfectly fine until the property would actually be needed. The nice thing about properties is that when changing a public field "public readonly int Id" to a property "public int Id { ... }" you don't require any change of calling code. This is really the main benefit of properties over get/set methods.

Now: getters and setters are very useful once you need them. And you don't need them until you do. But there are many good reasons for them: invariants/validation and interfaces are probably the most common.

Re: Data Classes for Java

#160

Post by unscaled »

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.

Then what are the design patterns for Scala?
Post reply on HN