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

131–140 of 216 posts

Re: Data Classes for Java

#131

Post by platz »

geophile wrote: post #42
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 think getters/setters are an abomination resulting from a sensible OO idea taken too far. Having private fields and public methods has benefits that are so obvious that I won't belabor the point. Sometimes -- maybe even often -- you really do want to get and set some fields, so then you have getters and setters. But applying this pattern blindly, to all fields, is insane and, as many people on this thread have note…

just use a struct for plain data

Re: Data Classes for Java

#132

Post by wvenable »

HumanDrivenDev wrote: post #115
wvenable wrote: post #105

Earlier quoted context omitted.

This seems to deny the fact that a lot of data exists to just be stored and displayed. Probably 85% of all software in the world has a "FirstName" field/property/column in it somewhere. What name you propose giving a method that changes that value?

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.

Re: Data Classes for Java

#133

Post by ScottBurson »

HumanDrivenDev wrote: post #33
drizze wrote: post #14

Earlier quoted context omitted.

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.

But by definition getters and setters lack lexibility. They expose the internal representation of an object. They stop really being "objects" - high level opaque things you send messages to - and they turn into big porous bags of fields. To clarify, I would not consider something like this a setter: class Monster { int health; void Damage(int d) { this.health -= d; } } True, it is a method that just sets a variable.…

This is a good argument and I have considerable sympathy with it, but it's actually not an argument against using getters and setters; it's just an argument for making them nonpublic. In a tiny example like this it obviously doesn't matter, but in a large, complex class it can be useful, in my experience, for all assignments to a field to go through a setter. As others here have argued, this provides a convenient hook for changing the behavior of all such assignments -- a hook which is maybe not often needed, but very useful when it is needed.

That said, I don't agree with your argument in all cases. Some classes really are relatively passive carriers of data. My favorite example is AST node classes in a compiler; the logic that controls the transformations applied to these is naturally outside the classes, because most of the interesting postconditions and invariants apply to the entire AST of which each node is only a small part.

Re: Data Classes for Java

#134

Post by AlphaSite »

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

Aside, from what the other poster mentioned, one major advantage is that I don't want to write getXXX and setXXX, everywhere where I do need computed properties, does it matter if the value is precomputed or lazy computed (for example for a float derived from another float)?

Re: Data Classes for Java

#135

Post by guelo »

dangets wrote: post #93
Naac wrote: post #89

Earlier quoted context omitted.

data class Animal(dog: String, numberOfLegs: Int) and Animal dog = Animal.builder() .setName("dog") .setNumberOfLegs(4) .build(); are very different. In this case the builder pattern is more powerful as it lets you pass around builders that haven't been "built" yet. Kind of like currying.

True, but the constructor method is checked/validated at compile time vs. run time with the builder pattern. Not quite the same as your example, but Kotlin does have good syntax for copying data classes while only changing a single field - this could be used similar to your currying usage. https://kotlinlang.org/docs/reference/data-classes.html#copy...

Here's that kotlin copy syntax

      val cat = dog.copy(name = "cat")

Re: Data Classes for Java

#136

Post by wvenable »

flukus wrote: post #87
hackinthebochs wrote: post #78

Earlier quoted context omitted.

I don't understand your complaint. The problem with getters and setters was the substantial tedious boilerplate required. C# completely does away with that to where there is no meaningful difference between the two in terms of typing required, while at the same time providing the benefit of encapsulation. So what's the problem? Do you really object to 14 more chars to type? That's absurd.

> The problem with getters and setters was the substantial tedious boilerplate required The problem isn't the tedious boilerplate, it's that it isn't necessary most of the time, 99%+ of getters and setters could be replaced with public fields. c# solved a problem that only existed in the first place because of cargo cult practices. > while at the same time providing the benefit of encapsulation It potentially provide…

> 99%+ of getters and setters could be replaced with public fields.

Actually it makes more sense the other way around. Fields are just an optimization; the different between fields and properties is one has direct memory access and the other is a method. Properties/methods are far more powerful: their implementation can change, they can be virtual and overridden, etc.

Maybe we could have had just properties and the JIT could have optimized them into direct memory access if they were backed by a simple field.

Re: Data Classes for Java

#137

Post by HumanDrivenDev »

wvenable wrote: post #129
HumanDrivenDev wrote: post #117

Earlier quoted context omitted.

It looks like I have a really different definition of "getter" than some people here. I would only call something a getter if it explicitly makes reference and effectively exposes an internal field. Just giving a method a noun name is not enough to make it a getter, in my mind. It's the "get" prefix that says 'hey there is definitely a field in here called Foo that we think we're encapsulating but we're really not'.

Your definition of getter and setter are way too narrow. You exclude all getXX() and setXX() methods that don't directly manipulate a field and all C# property get/set the same way. The getter or setter is part of the public interface of the object. The public interface makes no guarantees about implementation -- encapsulation is one of the fundamental principles of OOP. It is only supposed to appear from outside tha…

I think you're not understanding what I'm saying. Luckily this person explained it better than I could.

https://news.ycombinator.com/item?id=15607598

Re: Data Classes for Java

#138

Post by nikolay »

aisofteng wrote: post #82
avemg wrote: post #53

Earlier quoted context omitted.

Probably to avoid making 'data' a reserved word and breaking a ton of code that used 'data' as a variable name. Prior to Java 5, 'enum' was a very popular variable name too.

I'm having a difficult time trying to think of a case where "data" is the best variable name for anything.

Plus, it's 2017! There are so many tools to do a semantic search and replace and replace all variables, parameters, etc. called "data" with, let's say, "__data__". Why uglify the language instead of providing a migration tool like Python's 2to3?!

Re: Data Classes for Java

#140

Post by andmed3 »

guelo wrote: post #37
tantalor wrote: post #25

AutoValue with Builders is nice: Animal dog = Animal.builder() .setName("dog") .setNumberOfLegs(4) .build(); https://github.com/google/auto/blob/master/value/userguide/b...

Not that nice compared to kotlin: data class Animal(dog: String, numberOfLegs: Int) val dog = Animal( name = "dog", numberOfLegs = 4 ) The amount of boilerplate for AutoValue builders is so ridiculous that most people use IDE plugins to generate it.

Agreed. The amount of boilerplate is reduced significantly in Kotlin. it has builder methods also which help greatly with data classes like apply(), with() and let() for us it became language of choice for backend for these reasons
Post reply on HN