Thanks for sharing these writeups! They clearly cover the design space and as always evidence the significant thought and effort put into this feature.
I've read though most of the email threads related to these topics but may have missed discussion of these items elsewhere. Redirection to existing threads appreciated.
> Reconstructors:
There are a couple of areas that I'd like to highlight as I see potential repercussions for the language and broader ecosystem that are worth further discussion. The overall direction looks good so I'll only reference the areas of concern.
The first is the "Making names significant" section [1]:
> Making the parameter and binding names of constructors and deconstructors significant was
> needed for this feature (and, as it turns out, for a number of other desirable features
> too.) We surely can't just say "from today on, they are significant", but we can give
> people an opt-in to significant names. For purposes of exposition within this document,
> we'll use the modifier __byname on a constructor or deconstructor to indicate that names
> are significant.
> Making the parameter and binding names of constructors and deconstructors significant was
> needed for this feature (and, as it turns out, for a number of other desirable features
> too.) We surely can't just say "from today on, they are significant", but we can give
> people an opt-in to significant names. For purposes of exposition within this document,
> we'll use the modifier __byname on a constructor or deconstructor to indicate that names
> are significant.
I appreciate this is an opt-in feature given Java, as you point out, has historically not made names significant (though the MethodParameters classfile attribute provides some precedent).
Aside: My understanding of the MethodParameters attribute is that it's intended more as an informational than API and unlikely to affect application behaviour at runtime.
Aside: My understanding of the MethodParameters attribute is that it's intended more as an informational than API and unlikely to affect application behaviour at runtime.
Making names significant and part of the API will affect refactoring and separate compilation: developers are used to being able to freely rename parameters without worrying about affects on other parts of their code base or about breaking their consumers (library authors). Are there things the language can do to help with name transitions? Is treating parameter name changes in a __byname method as a breaking API change something that developers will have to adapt to?
Similarly libraries that implement a common specification (Java EE, etc) have historically allowed each implementation to name the parameters in ways that made sense for their implementation. I can see this becoming "names are API, live with it" which is a reasonable answer but one that will take some time to filter thru the ecosystem after the feature is released. Any concerns that adopting this feature forces a "flag day" on consumers of such libraries with all implementors needing to move in lockstep?
In the "Refining overloading" section [2]
> Each __byname constructor / deconstructor can be invoked positionally, so it must follow
> the existing rules for overloading and overload selection. A set of __byname members is
> valid if and only if for each two such members, their name sets are either disjoint or one
> is a proper subset of the other and the types corresponding to the common names are the same.
> Each __byname constructor / deconstructor can be invoked positionally, so it must follow
> the existing rules for overloading and overload selection. A set of __byname members is
> valid if and only if for each two such members, their name sets are either disjoint or one
> is a proper subset of the other and the types corresponding to the common names are the same.
This seems like an answer to the refactoring concerns above as it provides a way to leave previous API points around to not break consumers. Will the normal deprecation schemes apply to these name-only overloads? If so it covers most of the refactoring concerns - though the need to leave the old API points is a bit of code smell that may discourage some kinds of refactoring. Time will tell.
Is the intention that the VM would check the disjoint constraints during classloading? I can see it being pushed to the VM to validate or left as a language level rule with the VM's resolution taking the first available match. At first glance, both seem reasonable though VM validation will incur startup costs and would need more clarity on how checks for duplicate __byname constructors would mesh with the "Factories" proposal, either disjoint or combined checks? Details to be worked out as the proposal progresses.
Regards,
--Dan
--Dan
----- Original message -----
From: Brian Goetz <brian.go...@oracle.com>
Sent by: "amber-spec-experts" <amber-spec-experts-r...@openjdk.java.net>
To: amber-spec-experts <amber-spec-experts@openjdk.java.net>
Cc:
Subject: [EXTERNAL] A peek at the roadmap for pattern matching and more
Date: Wed, Aug 12, 2020 4:44 PM
Several folks have asked that I sketch out a little more of the roadmap for pattern matching, so that we can better evaluate the features being discussed now (since, for example, the semantics of pattern matching are heavily influenced by nested patterns.)
I've checked into two drafts which are VERY ROUGH, but which correspond to the next two logical increments after patterns in switch.
Deconstruction patterns:
https://github.com/openjdk/amber-docs/blob/master/eg-drafts/deconstruction-patterns-records-and-classes.md
This document outlines the semantics of deconstruction patterns and nested patterns, and declaration of deconstructors in classes.
Reconstructors:
https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md
This one addresses the challenge of "mutating" immutable objects such as records and inline classes, and builds on deconstructors.
(There are some teasers for related features, mostly to put these in context, but I don't want to get distracted on those features until these are nailed down, so take them as merely context.)
