Pattern method names based on existing library conventions [was Re: Pattern matching for nested List with additional size constraints]

[Brian Goetz]

> Reading this again, I agree that the
> "empty" name is important. But the "of" name is noise.

While I understand where you are coming from in this particular example, 
I think you are still stuck in the "old" mental model. (Which is 
understandable, you have to give yourself time with it.)

There's a powerful symmetry between `Optional.of(x)` and `case 
Optional.of(var x)`; it underscores the inverse relationship of the two 
members (actually: embedding-projection.)   I think you are still 
valuing that at zero, when in fact it is worth a lot, and you're tossing 
it away to avoid a few characters of "noise".

To recap: one of the values of this symmetry is that it provides us with 
a basis for interpreting

     case Foo(var x, var y):

as "Could I have constructed this thing from `new Foo(x, y)`, for some x 
and y, and if so, which?"  You don't have to run to the Javadoc to 
understand what the pattern does, because it does exactly the opposite 
of what its dual member does.  (If you actually code like this, the 
duality enables some really powerful things to be mechanically layered 
atop matching ctor/dtor pairs.   Records will automatically work like 
this.)

To make a possibly bad analogy, one of the few redeeming things about 
the JavaBean coding conventions is that they allowed tools and 
frameworks to reason mechanically about things like "getX and setX refer 
to the same abstract property X" (assuming suitable ad-hoc constraints 
on naming and signatures.)  This allows DSLs to let you say things like 
`x = x + 1` and have it mechanically map to `setX(getX() + 1)`.  Imagine 
the confusion on the part of both users and tools if there was no way to 
relate the getter and setter for a given property without consulting a 
complex decoder chart because arbitrarily different mechanisms were used 
for the two.

I think you're trying to make "locally optimal" choices, which makes 
sense, but when the decisions are related, this may well not result in a 
globally optimal outcome.