News for hackers. Stuff that matters.
Re:Java's records, Lombok's data, and Kotlin's data classes by ramblerman on Friday May 07, 2021 @01:24PM (#27078417)
> 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.

I'm not sure if you've debugged much, or inherited any large legacy projects, but knowing it is immutable vs "typically it isn't" is a pretty big distinction in that moment.

Re:Java's records, Lombok's data, and Kotlin's data classes by AtNightWeCode on Friday May 07, 2021 @02:04PM (#27078837)
Good code don't have this issue.
Re:Java's records, Lombok's data, and Kotlin's data classes by slver on Friday May 07, 2021 @02:15PM (#27078975)
Good code doesn’t have concepts like “typically doesn’t mutate”. It’s either mutable or immutable.
Re:Java's records, Lombok's data, and Kotlin's data classes by AtNightWeCode on Friday May 07, 2021 @02:33PM (#27079214)
The standard way to do it is to mutate clones as always in Java. Typically by use of libraries that provide this. You really need very bad code to have to think about if objects are mutable.
Re:Java's records, Lombok's data, and Kotlin's data classes by slver on Friday May 07, 2021 @02:38PM (#27079273)
Apparently you don’t know most immutable structures are optimized for modified cloning in ways mutables aren’t.
Re:Java's records, Lombok's data, and Kotlin's data classes by AtNightWeCode on Friday May 07, 2021 @05:53PM (#27081283)
This is Java.
Re:Java's records, Lombok's data, and Kotlin's data classes by slver on Saturday May 08, 2021 @02:38AM (#27084539)
And?
Re:Java's records, Lombok's data, and Kotlin's data classes by marcodave on Saturday May 08, 2021 @10:22AM (#27087374)
good code shouldn't need to be debugged either ;)