Next up for patterns: type patterns in switch
forax at univ-mlv.fr
Thu Jul 23 22:15:31 UTC 2020
On July 23, 2020 9:05:08 PM UTC, John Rose <john.r.rose at oracle.com> wrote:
>On Jul 23, 2020, at 11:38 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> In next releases? Add constant Pattern and static Pattern. Ban
>instance pattern because you don't want to match something that depends
>on a mutable states (my worst experience with Scala).
>Do you mean mutable states in some sort of pattern token (which is
>not AFAIK on the table) or mutable states in the object-being-tested
>or mutable states in a pattern parameter (e.g., an object being
>to the object-being-tested)? In the latter two cases, the mutability
>is that you test an object and it passes a test on Tuesday but not
>either because the object changed, or the *other* object hanged.
>I see there are horrible bugs there, but for Java that ship is already
>Object::equals/hashCode can depend on mutable state; equals can depend
>on mutable state in the second operand. Programmers just have to deal
>with it, or choose to use immutables (inlines! records!).
It's not because there are some loaded guns here and there that we should not try to avoid to add more.
>Patterns amount to a more generous slice of the functionalities
>which Object::equals/hashCode also serve. If we try to “tighten up”
>some aspect of patterns to avoid mutability bugs, we’ll just force
>users to drop down to Object::equals, for no strong reason IMO.
I hate to have to run my app only on Tuesday is a good reason.
The current switch is limited to non mutable class is another good reason and forcing users to explicitly use equals when something is mutable is not that bad too, ok it's less magical. But being able to understand the code is still more important that writing it.
>Banning instance patterns (while allowing static patterns) just puts
>in a cardboard wall that makes it slightly harder to code some bugs
>but will greatly annoy legitimate designers and users.
As you said records and inlines are ok,
Why not restricting instance patterns to them.
>(Or do I misunderstand your point?)
I want at least to be sure we have tried to corral mutable objects.
More information about the amber-spec-experts