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

211–216 of 216 posts

Re: Data Classes for Java

#211

Post by cultvoid »

jt2190 wrote: post #191
cultvoid wrote: post #177

Earlier quoted context omitted.

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 th…

> I only quibble on the "mindlessly" part. I'll grant that you're mindful ;-)

You overestimate my abilities! I mindfully create a horribly coupled mass of Spaghetti. But it's not anaemic spaghetti ;-)

Re: Data Classes for Java

#212

Post by vpalanc1 »

millstone wrote: post #76
geophile wrote: post #66

Earlier quoted context omitted.

I really, really dislike Swift's approach. get/set/willSet/didSet -- so much complication to preserve the illusion that you are operating on a field when you are actually doing no such thing. Why is this desirable? It reminds me of a class of C++ footguns where some innocuous code is actually invoking member functions due to operator overloading. I think that Java got this one right. (I do not at all like the cargo c…

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?

YAGNI. Seriously. That pretty much describes the main problem with Java - "maybe we'll need this coffee maker to also do julienne fries in the future!"

Re: Data Classes for Java

#213

Post by sushisource »

ben940830298432 wrote: post #21
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.

So if it became Kotlin?

To be fair I haven't really used Kotlin yet, but from my brief understanding the type system isn't quite as powerful, which is something I really like about Scala.

Re: Data Classes for Java

#214

Post by billrobertson42 »

emidln wrote: post #86
guelo wrote: post #37

Earlier quoted context omitted.

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.

In clojure I'd write this, if I actually needed a class for type dispatch or interface implementation for some reason. (s/defrecord Animal [name :- String number-of-legs :- Integer]) (def dog (map->Animal {:name "dog" :number-of-legs 4})) The nice thing is that I could also skip the defrecord if I just want enforcement of the shape of the data by making a similar defschema and then I'd just use plain maps.

I mucked around with records a lot early on while learning Clojure, and I'm not really sure when I stopped and just started using maps. Now it's second nature and I'd only consider using a record if there was some overriding performance concern.

Re: Data Classes for Java

#215

Post by billrobertson42 »

evacchi wrote: post #84
nikolay wrote: post #18

Why underscores in "__data"? Is this just a temporary thing?

It's decoy to avoid bikeshedding. The value class proposal used __value

When you say decoy, do you mean it's intentionally gross to keep people from going off on syntax debates?

Re: Data Classes for Java

#216

Post by digaozao »

whitenoice wrote: post #123
vaskebjorn wrote: post #29

Earlier quoted context omitted.

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: "…

You might want to look into Project Lombok. It does exactly that, and it works well.

Five years Ago I started to use it. Never touched a project without again. Today I am really interested in kotlin, which provides many of these features.
Post reply on HN