So what's the answer to the question? Pattern matching and destructuring? But I don't see any reason Kotlin data classes can't do that. I know Kotlin pattern matching is pretty lack-luster, but I never thought this was the reason.
Java's records, Lombok's data, and Kotlin's data classes
91–100 of 294 posts
Re: Java's records, Lombok's data, and Kotlin's data classes
#92Not sure why immutable data structures have surfaced as something important. Typically you never change fields so it is kind of only of academic value if a field in a POD, POJO, POCO or whatever it is called in the specific language actually may change.
Keyword being “may”.
Guarantees are nice. Especially if objects are going to be passed around every which way from Sunday. It allows you to better reason about what could happen, and where.
Java has taken a while to get there, but I’m glad that they have finally.
Re: Java's records, Lombok's data, and Kotlin's data classes
#93sorry -java .. better?
what?
why would anyone use java for anything?
let me give an example:
from a project a while(some years actually) ago i still have a license for a php-ide(zend). its in java. no chance in hell to get it working today.
meanwhile, stuff i did 2003 still runs on windows out of the box, even in wine/osx. so again: why use java for anything? https://twitter.com/abductee_org/status/711966430133026816 (try it https://www.pouet.net/prod.php?which=11247 )
oh and there is this: https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf so, double-again: why use java for anything?
Re: Java's records, Lombok's data, and Kotlin's data classes
#94Earlier quoted context omitted.
Getters are setters are pointless anyway - unless you're creating read-only properties by only providing getters, reflexively adding a getter and a setter for every property is exactly the same as just marking the property public. It's even worse in the case of immutable objects (like lists or maps), because the getter itself returns a reference to the mutable object. Getters and setters mentality came from a horribl…
get()/set() is the same as a public property, until you change the implementation, while maintaining interface compatibility, which is the point. In C# you'd have a point, they have parametric properties and readonly properties. So you'd favor just declaring public properties. But this is why context matters. And OO design principles also depend on this context.
> until you change the implementation, while maintaining interface compatibility, which is the point
How many times have you seen that done on the real world?
And how many times have you seen that done, and it not creating a lot of bugs because of the behavior change without interface changes?
Personally, I've seen the first one more than zero times. Not the second. Every single time somebody decided to mess with a setter or a getter, it broke the systems that depended on it, and things would have been much better if they simply changed the interface, so the problems would arrive at compile time.
Re: Java's records, Lombok's data, and Kotlin's data classes
#95Re: Java's records, Lombok's data, and Kotlin's data classes
#96Kotlin data classes can be used with the JPA contrary to Java records. It's good to encourage immutability, but it is often a misfit and isn't the role of a "data class", they could have added a separate class qualifier immutable that would have been a better separation of concerns, here it's ad-hoc. Kotlin is enabling such immutable support thanks to Java records ironically https://kotlinlang.org/docs/jvm-records.ht…
I'm really not sure if using data classes with JPA is smart idea. Solely because of generated hashCode/equals and JPA lazy loading. For instance ebean recommends against it [0].
Re: Java's records, Lombok's data, and Kotlin's data classes
#97Kotlin data classes can be used with the JPA contrary to Java records. It's good to encourage immutability, but it is often a misfit and isn't the role of a "data class", they could have added a separate class qualifier immutable that would have been a better separation of concerns, here it's ad-hoc. Kotlin is enabling such immutable support thanks to Java records ironically https://kotlinlang.org/docs/jvm-records.ht…
> Kotlin is enabling such immutable support thanks to Java records ironically
That a member of the JVM ecosystem is leveraging new JVM capabilities isn't ironic, it's totally expected.
Re: Java's records, Lombok's data, and Kotlin's data classes
#98Earlier quoted context omitted.
You have to copy less than you think. Because the data is immutable, you can share everything but the changed fields.
Then you've invented mutability without references/identity. Except those are desired properties for data classes, unlike for value classes which have such semantic difference. Btw Kotlin allow to make immutable Java records too so clear winner.
Not sure what you're getting at. Immutable means exactly that. If you hand out an object, then do a copy change, that change isn't reflected in the object you gave to another method/thread/fiber/etc. Immutability doesn't mean application state never changes; it means that a single reference will always point to memory that hasn't changed.
Re: Java's records, Lombok's data, and Kotlin's data classes
#99I'm not sure what it's taking about for the "with" feature: https://nipafx.dev/java-record-semantics/#with-blocks In Kotlin data classes, it's already implemented (just called copy) https://kotlinlang.org/docs/data-classes.html#copying
It was included because changing data using records (copying it except changing the fields you need to change) is a shitty experience, so rather than showing the code you have to write, they showed you code you may or may not in the future be able to write.
Re: Java's records, Lombok's data, and Kotlin's data classes
#100Earlier quoted context omitted.
In languages without property support, reflexively writing getters and setters is the only way to make it possible to go back later and add logic to getting and setting without changing the callsites. Is this a workaround for the combined shackles of mismanaged enterprise environments where changing callsites is impossible for some reason, and legacy language environments where you have to use Java for some reason? Y…
> go back later and add logic to getting and setting Which, realistically, you're virtually never going to do - at least not often enough to justify the boilerplate and especially in the case of things like "records" which were probably auto-generated from a schema (with obligatory getters and setters) anyway. If you did , you'd end up confusing all of your callers who probably wrote client code presuming that what t…
Agree, for a lot of code you can be pretty sure it will not change. And you should be able to refactor your code base, if not there are larger issues.
In general I subscribe to the at first make it as simple as possible, when you have two examples of it being too simple it is time to refactor.
Of course when creating libraries it is different. In that case to protect users on the API surface and try to make that stable.