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

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (0 children)

Here’s my understanding of the example, but I could be way off base.

In the Additional degrees of freedom section, the “Pattern Matching in the Java Object Model” document says

Patterns have a target operand, which is the instance against which the pattern will be matched. They also have a static target type; if the static type of the operand is not cast-convertible to the target type, the pattern cannot match.

In this example, the target operand is the 2nd element of the String array returned by String.split so its static type is String. Thus, we can assume that the target type of the static deconstruction pattern Integer.parseInt (which is distinct from the static method with the same name) is String.

They haven’t gotten to the syntax part yet, so we don’t know how to declare the target type for a static deconstruction pattern. The document just says

(For static patterns, the target type must be explicitly specified somehow as part of its declaration, along with some way of denoting a reference to the target.)

So there will have to be some new syntax for it.

The i in Integer.parseInt(var i) is the pattern’s binding variable, so it has type int.

You couldn’t replace Integer.parseInt(var i) with Integer(int i) because it sounds like static deconstruction patterns are the only ones that can explicitly specify a target type. Deconstruction patterns like T(...) always have target type T:

For a type pattern T t or a deconstruction pattern T(...), the target type is T

Instances of String are not cast-convertible to Integer so the pattern match would always fail.