Updated Draft specs for JEP 359 (Records)

Tue Dec 3 15:32:38 UTC 2019

Looks good to me, thanks.

вт, 3 дек. 2019 г., 20:00 Gavin Bierman <gavin.bierman at oracle.com>:

> I have made a further change to the online version.
>
> There was a missing case in 8.10.3, as it should be required that an
> explicitly declared accessor method is not static.
>
> Gavin
>
> gbierman$ hg diff -c 30704:012cc50cb363
> diff -r 9f5a21334115 -r 012cc50cb363 closed/src/
> java.se/share/specs/records-jls.md
> --- a/closed/src/java.se/share/specs/records-jls.md     Thu Nov 28
> 14:06:43 2019 +0000
> +++ b/closed/src/java.se/share/specs/records-jls.md     Tue Dec 03
> 11:27:03 2019 +0000
> @@ -2433,6 +2433,8 @@
>
>    - The accessor method must be declared `public`
>
> +  - The accessor method must not be declared `static`
> +
>    - The accessor method must not have a `throws` clause
>
>    - All other rules for a method in a normal class declaration must be
>
>
> > On 26 Nov 2019, at 14:17, Gavin Bierman <gavin.bierman at oracle.com>
> wrote:
> >
> > Thanks Alex; have made these changes to the online version.
> >
> > Gavin
> >
> >> On 26 Nov 2019, at 02:23, Alex Buckley <alex.buckley at oracle.com> wrote:
> >>
> >> // Cutting amber-dev
> >>
> >> On 11/25/2019 3:23 PM, Gavin Bierman wrote:
> >>>
> http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jls.html
> >>
> >> The JLS draft is good. Some technical rewordings:
> >>
> >> 1. 8.10.3: "and the type as the declared type" -- missing a "same"
> >>
> >> 2. 8.10.3: Say "This field is annotated with the annotations, if any,
> that appear on the corresponding record component and whose annotation
> types are applicable in the field declaration context or in type contexts
> or both."  (Later, for implicitly declared accessor methods, the phrase
> "whose annotation type is" should be "whose annotation types are". We do
> not constrain all the annotations to have the same annotation type, nor all
> the annotation types to be applicable in the same way. You could introduce
> an existential qualifier if you like -- "For each annotation A that appears
> on the corresponding ..." -- but I don't think it's necessary.)
> >>
> >> 3. 8.10.3: "A method ***declared*** in a record type R is said to be an
> accessor method" -- this raises questions of "explicitly or implicitly".
> It's too easy to think it means "explicitly" when that's not always true.
> Sidestep the problem by speaking more directly: "In a record type R, an
> _accessor method for a record component_ is a method whose name is the same
> as the name of the record component, and whose formal parameter list is
> empty." Then some refactoring because long list items are hard to follow:
> >>
> >> -----
> >> For each record component appearing in the record component list:
> >> 1. An implicitly declared private final field ...
> >> 2. An accessor method for the record component. [THAT'S IT. DON'T RULE
> ON THE FORM OF EXPLICITLY DECLARED METHODS HERE. JUST MAKE SURE ALL THE
> METHODS EXIST:]
> >>
> >>  If an accessor method for the record component is not explicitly
> declared, then one is implicitly declared with the following properties:
> >>  - The name is the same as ...
> >>  - ...
> >>
> >>  It is a compile-time error if the implicitly declared accessor method
> is override-equivalent (8.4.2) with a non-private method of the class
> Object. [THIS PARAGRAPH IS TROUBLE. PLEASE MAKE AN EXPLICIT RULE IN 8.10.1
> THAT SPELLS OUT IN CLEAR NORMATIVE TEXT THAT A RECORD COMPONENT MUST NOT
> HAVE BE CALLED CLONE, FINALIZE, ETC. RELYING ON A SUBTLE RULE IN A
> DIFFERENT SECTION ABOUT IMPLICITLY DECLARED STUFF IS *TOO HARD*. IT
> SUGGESTS THAT THE COMPILER SHOULD POSITION THE CARET FOR THE ERROR AT SOME
> POINT IN THE RECORD'S BODY, WHERE THE IMP.DECL. METHOD WOULD LIVE, RATHER
> THAN IN THE RECORD'S HEADER.]
> >>
> >> [ITEM 2 ENDS HERE. NON-LIST TEXT FOLLOWS.]
> >>
> >> If an accessor method for a record component is declared explicitly,
> then it must satisfy the following rules, or else a compile-time error
> occurs:
> >> - The return type of the accessor method ...
> >> - ...
> >>
> >> [THE FOLLOWING PARAGRAPH IS DISTINCTLY SURE -- "IS NOT ANNOTATED" --
> THAT AN EXPLICIT METHOD HAS NO ANNOTATIONS LIKE THE ONES ON THE RECORD
> COMPONENT. WHAT IF THE DEVELOPER WRITES ANNOTATIONS EXPLICITLY? PLEASE
> CHANGE THE PARAGRAPH TO AN INFORMATIVE NOTE WHERE YOU CAN SAY: ANNOTATIONS
> THAT APPEAR ON THE CORRESPONDING RECORD COMPONENTS ARE NOT CARRIED OVER TO
> EXPLICITLY DECLARED ACCESSOR METHODS, IN CONTRAST TO HOW IMPLICITLY
> DECLARED ACCESSOR METHODS ARE ANNOTATED ACCORDING TO BLAH BLAH.]
> >> An explicitly declared accessor method is not annotated with any
> applicable annotation that appears on the corresponding record component.
> >> -----
> >>
> >> 4. 8.10.4: It's odd to see in "derived constructor signature" that a
> ctor has a name R, since 8.8 doesn't admit to a ctor having a name. That
> said, 8.8.2 speaks of "two constructors with override-equivalent signatures
> (§8.4.2) in a class", and the definition of override equivalent implies a
> name is present, so I'll set my concern aside. Just a minor rewording for
> flow -- push derivation of formal parameter list down one level, as it's
> not used by anything else (OK, one place, but I'll get to that) :
> >>
> >> -----
> >> To support proper ... corresponding to the record components.
> >>
> >> A record type R has a derived constructor signature with the name R,
> with no type parameters, and with a formal parameter list that is derived
> from the record component list of R as follows:
> >>
> >> - For each record component ...
> >> -----
> >>
> >> 8.10.5: Construct good things, or else people will wonder:  "At most
> one compact constructor declaration can be declared for a record type." +
> "In a record type R, the signature of a compact constructor declaration is
> the _derived constructor signature_ of R (8.10.4)."   Don't say in
> normative text that "one which is derived from the record component list of
> R is added implicitly" -- "added" is too imperative -- this is an
> opportunity to write an informative note that compares and contrasts a
> compact ctor with all other ctors in Java -- "Unlike ctors in records, and
> indeed in classes in general, no explicit formal parameter list is given
> for a compact ctor. The record component list provides the X from which a Y
> is derived."
> >>
> >> Alex
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20191203/81b547d4/attachment.html>