3 ms·

I'm not talking about not allowing. I merely explained, because you asked, why pattern matching does not play well with mutation, and it doesn't. equals and has

by pron 7y ago

I'm not talking about not allowing. I merely explained, because you asked, why pattern matching does not play well with mutation, and it doesn't. equals and hashCode also don't play well with mutation, and indeed they are not automatically generated for mutable objects, but they are for records. As the author of a class you can provide a reasonable implementation of them, as well as of a deconstructor for pattern-matching, but that requires knowing more about the particulars of the class. There are other reasons for not allowing mutable records, but most -- including pattern matching -- can be summarized as "that's not what records are about, which is being 'dumb' data aggregates". You can read a more detailed discussion of the subject here: https://cr.openjdk.java.net/~briangoetz/amber/datum.html https://cr.openjdk.java.net/~briangoetz/amber/datum.html

mahkoh 7y ago
>I merely explained, because you asked, why pattern matching does not play well with mutation, and it doesn't. What you explained so far is that it doesn't play well with concurrent modification. And then I said that the "not playing well" comes from the concurrent part, not from the modification part. I'm less interested in the philosophy of records and more in the use cases they support.
- pron 7y ago
  > What you explained so far is that it doesn't play well with concurrent modification Fair enough. > I'm less interested in the philosophy of records and more in the use cases they support. The use cases and motivation, as well as why mutation is wrong for records, are explained in the links I provided. Here they are again: * https://openjdk.java.net/jeps/359 https://openjdk.java.net/jeps/359 * https://cr.openjdk.java.net/~briangoetz/amber/datum.html https://cr.openjdk.java.net/~briangoetz/amber/datum.html
  - smarks 7y ago
    Mutation without concurrency is still a problem for pattern matching. To return to your earlier example, suppose you've matched Point(3, y) and you're now in some code that assumes that the x-value of the Point is 3. Now, you call some method that has some reference to the point you're working on, and it mutates the x-value to 4. The assumption in that code after the match is now broken.
    - deleted 7y ago
      [deleted]
- deleted 7y ago
  [deleted]

by pron 7y ago

mahkoh 7y ago

>I merely explained, because you asked, why pattern matching does not play well with mutation, and it doesn't. What you explained so far is that it doesn't play well with concurrent modification. And then I said that the "not playing well" comes from the concurrent part, not from the modification part. I'm less interested in the philosophy of records and more in the use cases they support.

pron 7y ago
> What you explained so far is that it doesn't play well with concurrent modification Fair enough. > I'm less interested in the philosophy of records and more in the use cases they support. The use cases and motivation, as well as why mutation is wrong for records, are explained in the links I provided. Here they are again: * https://openjdk.java.net/jeps/359 https://openjdk.java.net/jeps/359 * https://cr.openjdk.java.net/~briangoetz/amber/datum.html https://cr.openjdk.java.net/~briangoetz/amber/datum.html
- smarks 7y ago
  Mutation without concurrency is still a problem for pattern matching. To return to your earlier example, suppose you've matched Point(3, y) and you're now in some code that assumes that the x-value of the Point is 3. Now, you call some method that has some reference to the point you're working on, and it mutates the x-value to 4. The assumption in that code after the match is now broken.
  - deleted 7y ago
    [deleted]
deleted 7y ago
[deleted]