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

41–50 of 216 posts

Re: Data Classes for Java

#41

Post by arthur_pryor »

HumanDrivenDev wrote: post #36
Tarean wrote: post #24

Earlier quoted context omitted.

If you have a temperature class with a celsius field and change the internal representation to kelvin you have to update all client code to call a conversion method. C#s syntax sugar allows you to slot in the conversion method without a breaking change but it screws with the cost model of field accessing when used unresponsibly. Java doesn't have it so you would have to hide everything behind getters if you don't wan…

I appreciate you thinking of an example, but I guess I find it a bit convoluted. Couldn't you also refactor that by changing the constructor of your temperature class so it converts things to Kelvins, rather than converting it every time you call the getter?

what if the constructor's not the only place you can set the value?

Re: Data Classes for Java

#42

Post by geophile »

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 noted, defeat the point of private fields and public methods. Just make the fields public, because that's how much protection you have anyway. (Adding code around the getting and setting is, of course, easier with methods already in place.)

I think this trend really got started with Java Beans, in which getters/setters were required (unless you wanted to write yet more code to nominate other methods as the getters and setters). And then the stupidity set in. Well why wouldn't you want your object to be a bean? Beans are good! Be a bean.

I believe that things like corporate coding standards then kicked in and made this nonsense unavoidable.

Re: Data Classes for Java

#43

Post by arthur_pryor »

opmac wrote: post #11
iamandoni wrote: post #4

Earlier quoted context omitted.

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?

i'm a little rusty on my java, but i don't think this will work for non-constants (i.e. it won't work for things you don't set at compile time).

to my knowledge, there's no "make this a constant after the first time the value is set" declaration in java (or any language that i'm aware of).

Re: Data Classes for Java

#44

Post by HumanDrivenDev »

moron4hire wrote: post #35
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 don't get to execute validation code on a bare field right away.

Why not give your "setters" a real name that describes what they're doing?

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

In the structs & records world (C, F#, Rust, etc) they never seem to have this issue. Either the struct is completely transparent and you can read and write fields at will, or it's completely opaque and the functions that operate on it have better names/semantics than "setField".

Re: Data Classes for Java

#45

Post by Matthias247 »

eropple wrote: post #26
bognition wrote: post #6

Honestly immutable data classes that are created via builders is a must have in Java.

Is there something that a builder gets you that Kotlin-style data classes doesn't?

Builders can set multiple fields of the data class at once, e.g. from a single builder parameter. They also can perform error checking whether the thing that the user actually wanted to build is consistent before returning a data class. There might be multiple fields in a class where the value of one field restricts possible values of another one.

These are already some reasons why you want users to create objects through builders instead of initializing them directly.

Another thing that builders provide is interface isolation: If your data class is only interpreted by your own libraries code you can modify it's (package-private) content as you like and require. The builder can evolve (and fill in additional fields as needed), and your code which consumes the built data class can evolve without breaking a user contract. Just the builder API needs to be stable (or backward compatible). With data classes this wouldn't work that easy, since you require the user to specify more parameters directly.

Re: Data Classes for Java

#46

Post by jt2190 »

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.

Re: Data Classes for Java

#47

Post by tybit »

As the article starts out with, Algebraic Anny, Boilerplate Billy etc wanting different things, I wonder if rather than side stepping this issue with a compromise if they could solve it with metaclasses as proposed for C++ https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-ge...

I really like the idea of metaclasses and would love to see proposals for C# and Java too. As the proposal mentions Java and C# have already gone down a separate path with interfaces (and structs for C#) but would be cool to see if it could be resolved anyway.

Re: Data Classes for Java

#48

Post by dhosek »

arthur_pryor wrote: post #43
opmac wrote: post #11

Earlier quoted context omitted.

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

i'm a little rusty on my java, but i don't think this will work for non-constants (i.e. it won't work for things you don't set at compile time). to my knowledge, there's no "make this a constant after the first time the value is set" declaration in java (or any language that i'm aware of).

If you declare a field final in Java, you either need to set it at declaration or in the constructor, so it will work with things set at compile time.

Re: Data Classes for Java

#49

Post by HumanDrivenDev »

Tarean wrote: post #38
HumanDrivenDev wrote: post #36

Earlier quoted context omitted.

I appreciate you thinking of an example, but I guess I find it a bit convoluted. Couldn't you also refactor that by changing the constructor of your temperature class so it converts things to Kelvins, rather than converting it every time you call the getter?

Sure, but every field access like Temperature temp = Temperature.fromCelsius(13); ... System.out.println(temp.celsius); would have to be changed to System.out.println(temp.getCelsius()); when the internal representation is changed.

I get what you're saying, but at the same time I don't understand how you'd implement the class and why.

    class Temperature {   
        public final double celcius, kelvins;

        Temperature(int celcius, int kelvins) {
            this.celcius = celcius;
            this.kelvins = kelvins;
        }
        
        public static Temperature fromCelcius(int c) {
            return new Celcius(c, c - 273.15);            
        }
    }
What's wrong with that approach, and how would you do it?

Re: Data Classes for Java

#50

Post by virmundi »

Can’t we just use AOP to generate the boilerplate code if we are ok with Kotlin style data types? Toss an annotation on the class like @Data. After that everything should get generated at compile time.
Post reply on HN