Comment on JEP 305

[Tagir Valeev]

Hello!

1. Current instanceof is just a first step towards a pattern matching,
destructuring patterns cannot be expressed via flow typing and it
would be weird to introduce both features.
2. It's impossible to change existing Java to support flow typing
without breaking existing programs. E.g.:

static void test(Object obj) {
 if (obj instanceof char[]) {
  System.out.println(obj);
 }
}

If we allow flow-typing, then the println call should be rebound to
another method accepting char[] array, changing the program semantics.
It would be a compatibility disaster, much worse than e.g. simply
making some programs non-compilable. To introduce flow-typing in a
compatible way we would need to invent a new instanceof operator and
ask everybody to use it in new code. It's dirty and unlikely people
would adopt it soon.

3. Note that the left part of instanceof is not necessarily a
variable. It could be a field, an array, a method call or other kind
of expression. In all of these cases, flow typing would be useless
while variable introduction works consistently. I saw dozens of
complaints about Kotlin, like you change an immutable property to a
mutable, and boom: flow typing is broken everywhere within your class.
Proposed Java pattern matching doesn't care: it will still work.

With best regards,
Tagir Valeev.

On Wed, Jan 8, 2020 at 7:47 PM <alex at syncwords.com> wrote:
>
>
> First of all, let me start by saying that I wish there were a better place for the general public to provide feedback to proposed language changes. I understand that this feedback can get overwhelming, but it's also bizarre to have an "open" process and release public "preview" features but with few avenues, other than this list and, I guess, Twitter, for the wide, experienced, and plenty wise Java community to give feedback.
>
> Specifically, I want to share my feedback regarding the "Pattern Matching for instanceof" feature. I think "flow typing" is a great idea, and I don't like the current JEP 305 proposal because it forces the declaration of a new variable. Declaring a variable is onerous because each variable needs a good name. It is difficult to think of a good name for a variable that redeclares another variable which already has a good name. Moreover, having two names for the same variable hurts readability. It also breaks refactoring. Additional problems are weird constructs like if (!(a instanceof Foo b)). Flow typing is more general.
>
> There is no reason given for why the variable should be renamed, other than claimed harmony with a future, major language expansion under the banner of pattern matching. I hope that expansion does not make it. I read over Brian Goez's and David Bierman's document. What I have to say is this: Every language is shaped by the kinds of programs their authors write. Java was and is a general-purpose language that followed and (to a lesser extent) still follows the Keep It Simple, Stupid principle. The pattern matching proposal, however, seems like syntactic sugar written by and for programmers working on AST parsers. Not a lot of people work on those. (Incidentally, I dabble in them, and even I don't think it's worth trying to replace a mess of if statements with a mess of switch clauses, and then add chapters to Java books to explain how it all works.) If we're going to pick a use-case that is poorly addressed by the Java language, it should be scientific computing and AI (numpy, pytorch, etc). These would benefit from operator overloading and range expressions.
>
> Aleksandr Dubinsky