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.

Reply via email to