Reader mail bag

[Brian Goetz]

We've gotten two submissions to the amber-spec-comments list.

1.  "Forcing a pattern match", at: 
http://mail.openjdk.java.net/pipermail/amber-spec-comments/2017-November/000000.html

2.  "Named parameters in data classes", at: 
http://mail.openjdk.java.net/pipermail/amber-spec-comments/2017-November/000003.html


I think the first asks for an alternate form of the "matches" operator 
which would fail with a CCE, rather than evaluating to false, if the 
match fails.  This would be essentially saying, "This should match; if 
it doesn't, that's an error."  I think that's what's being asked, but 
then he talks about an "unnecessary instanceof check", which makes me 
wonder whether this is really just about optimization.

To be clear, the instanceof check is neither expensive nor unnecessary.  
(Though we can optimize these away when we know the static type of the 
target; if x is a Foo, then "x matches Foo f" can be statically 
strength-reduced to "x != null".)

Note that the "if member.getKind() == VARIABLE" is merely a manual 
optimization; you could easily leave that out and just match against 
VariableTree.  What we'd rather focus on is how to get to:

     switch (member) {
         case BlockTree bt: ...
         case VariableTree vt: ...
     }

while allowing the pattern to capture the quicker pre-test (kind == 
BLOCK) and maintain the performance without making the user worry about 
this.  We have some ideas here, but I don't think this "forcing" idea 
really offers a lot.


The second (named parameters) was a question I was expecting.

I agree that being able to invoke constructors and methods by name can 
sometimes result in easier-to-read code, especially when some parameters 
have a sensible default value.  (This is also a more complicated feature 
than anyone gives it credit for, so it's not the "gimme" it is often 
assumed to be.)

However, data classes is not the place to cram in this feature; this 
should be a feature that stands on its own, and applies to all classes, 
data- or not.  One of the design goals for data classes is that a data 
class should be essentially a "macro" for a class you could write by 
hand; this allows easy migration from existing classes to data classes 
(if they meet the requirements) and from data classes to full classes if 
they expand to no longer fit the data class profile.  The more that 
*uses* of data classes or their members are different from the 
corresponding use of regular classes, the more difficult this migration 
becomes.  (This is not unlike the design mandate with default methods; 
from the client perspective, they're just ordinary virtual methods, and 
you can't tell whether the method was implemented directly or inherited 
-- they're just methods.)

So, while named parameters are a reasonable feature to explore, trying 
to staple them onto data classes would be a mistake.  They are their own 
feature.  We're open to exploring it, but we've got our plate full for now.