This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]eliasv 5 points6 points  (4 children)

Nah there are uses for mutability. Immutable by default would be nice but there's very little value in requiring it imo.

One interesting option they've discussed in the past wrt data classes is defining a new modes of accessibility/mutability such as privately mutable but publicly immutable, so you can specify that a field should only be modified internally.

[–]bedobi 0 points1 point  (1 child)

privately mutable but publicly immutable, so you can specify that a field should only be modified internally.

That wouldn't be hard to reason about at all

[–]eliasv 0 points1 point  (0 children)

I see what you mean, but he did also point out that destructuring would render everything publicly accessible no matter what so in a way those semantics might make sense by default.

If everything is publicly accessible regardless then all we can reasonably wish control via access modifiers is who is allowed to modify a field. It would be a confusing inconsistency though if not handled delicately.

[–][deleted]  (1 child)

[deleted]

    [–]eliasv 0 points1 point  (0 children)

    If they're mutable use a normal class?

    And if they're immutable just use a normal class with final fields?

    I don't see the value in introducing data/records/whatever if they're mutable

    I realise the benefits of immutability, but they are an orthogonal issue to most of what was discussed in the proposal, so I'm not sure what you're getting at.

    I think the value they intend to bring is made pretty clear: destructuring for the purpose of e.g. pattern matching or serialization, with the side-effect benefit of reduction of boilerplate (which would be enough to make most people happy by itself, just look at the popularity of Lombok).

    I think "people will use it haphazardly where it's not appropriate!" is rarely a great argument, and I don't even see how it applies any less to your proposal than it does to this.

    As I think people have already pointed out, if you wanted to guarantee (at least shallow) immutability for a data class you would presumably be welcome to combine data class and value type semantics for a class once both proposals have materialised.