4 ms·

I think the article is misleading in the list of advantages over Kotlin's Data Classes. 1. Destructuring - available in Kotlin 2. Copy with change - available

I think the article is misleading in the list of advantages over Kotlin's Data Classes. 1. Destructuring - available in Kotlin 2. Copy with change - available in Kotlin 3. Serialization - not sure why Kotlin data class would not be serializable 4. Boilerplate - Kotlin takes care of equals and hashCode Huge disadvantage that matters to me is that record fields cannot be mutated. It makes the records much less useful.

throwaway4good 5y ago
"Huge disadvantage that matters to me is that record fields cannot be mutated. It makes the records much less useful." No. It makes them much more useful.
- throwpupper 5y ago
  Well it means that the second you need a setter you can't use records so all the boilerplate remains.
  - zaphar 5y ago
    Why would you need a setter for a data class? They add no value there.
    - deleted 5y ago
      [deleted]
  - valenterry 5y ago
    You are supposed to create a new copy with some of the fields changed. Just like you do it with the java.time.* classes and others.
    - bcrosby95 5y ago
      Yet the only mechanism for this is error prone or relying on mountains of boilerplate.
    - vbezhenar 5y ago
      Instead of changing few bytes, now I have to copy hundreds of bytes around and add more stuff for GC to collect. Well, they have to obey Wirth's law, I guess.
      - JackFr 5y ago
        You have to copy less than you think. Because the data is immutable, you can share everything but the changed fields.
        The_rationalist 5y ago
        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.
        pkulak 5y ago
        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.
        kaba0 5y ago
        Parent means basically the difference between identity and primitive/value classes. In Haskell, you’ve only got the latter (maybe you can manage something with lower level controls exposed), that is in a non-haskell syntax new Point(3,2) == new Point(3,2), even though in memory the two object is different. “Problem” is with records, that they are only shallowly immutable. record Rect(List<Point> corners) will readily hand out a “pointer” to a mutable list. It can be solved of course by storing only immutable objects. What parent may have failed to get from grandparent comment is that the latter likely meant it under the hood, transparently to the user. That is, new Point(3,2) != new Point(3,2) but the JVM can make the object reference the same data, because the field itself is final. Thus a copy can be optimized at the JVM level, while still having identity.
nicolai-parlog 5y ago
1. with possible loss of information 2. as API, but an operator can do more 3. they are surely serializable, but they still need all the ugly reflection hacks that come with that (like bypassing the constructor and allowing the JVM to write to final fields) 4. that part was just presenting a benefit of records (on its own; not over Lombok/Kotlin), but the fact it's under the header "Why Records Are Better*" is confusing

throwaway4good 5y ago

"Huge disadvantage that matters to me is that record fields cannot be mutated. It makes the records much less useful." No. It makes them much more useful.

throwpupper 5y ago
Well it means that the second you need a setter you can't use records so all the boilerplate remains.
- zaphar 5y ago
  Why would you need a setter for a data class? They add no value there.
  - deleted 5y ago
    [deleted]
- valenterry 5y ago
  You are supposed to create a new copy with some of the fields changed. Just like you do it with the java.time.* classes and others.
  - bcrosby95 5y ago
    Yet the only mechanism for this is error prone or relying on mountains of boilerplate.
  - vbezhenar 5y ago
    Instead of changing few bytes, now I have to copy hundreds of bytes around and add more stuff for GC to collect. Well, they have to obey Wirth's law, I guess.
    - JackFr 5y ago
      You have to copy less than you think. Because the data is immutable, you can share everything but the changed fields.
      - The_rationalist 5y ago
        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.
        pkulak 5y ago
        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.
        kaba0 5y ago
        Parent means basically the difference between identity and primitive/value classes. In Haskell, you’ve only got the latter (maybe you can manage something with lower level controls exposed), that is in a non-haskell syntax new Point(3,2) == new Point(3,2), even though in memory the two object is different. “Problem” is with records, that they are only shallowly immutable. record Rect(List<Point> corners) will readily hand out a “pointer” to a mutable list. It can be solved of course by storing only immutable objects. What parent may have failed to get from grandparent comment is that the latter likely meant it under the hood, transparently to the user. That is, new Point(3,2) != new Point(3,2) but the JVM can make the object reference the same data, because the field itself is final. Thus a copy can be optimized at the JVM level, while still having identity.

nicolai-parlog 5y ago

1. with possible loss of information 2. as API, but an operator can do more 3. they are surely serializable, but they still need all the ugly reflection hacks that come with that (like bypassing the constructor and allowing the JVM to write to final fields) 4. that part was just presenting a benefit of records (on its own; not over Lombok/Kotlin), but the fact it's under the header "Why Records Are Better*" is confusing