On 10/11/19 6:50 PM, Maurizio Cimadamore wrote:
On 11/10/2019 22:19, fo...@univ-mlv.fr wrote:
- Mail original -
De: "Brian Goetz"
À: "Remi Forax" , "amber-spec-experts"
Envoyé: Vendredi 11 Octobre 2019 22:57:23
Objet: Re: Record attribute binary format
No need. Varargs-ness is
On 11/10/2019 22:19, fo...@univ-mlv.fr wrote:
- Mail original -
De: "Brian Goetz"
À: "Remi Forax" , "amber-spec-experts"
Envoyé: Vendredi 11 Octobre 2019 22:57:23
Objet: Re: Record attribute binary format
No need. Varargs-ness is reified with the (mandated) canonical ctor.
hum, th
- Mail original -
> De: "Brian Goetz"
> À: "Remi Forax" , "amber-spec-experts"
>
> Envoyé: Vendredi 11 Octobre 2019 22:57:23
> Objet: Re: Record attribute binary format
> No need. Varargs-ness is reified with the (mandated) canonical ctor.
hum, this looks like a hack, it means you can
On Oct 9, 2019, at 2:26 PM, Brian Goetz wrote:
>
> It is allowable, though somewhat silly, to put the `final` modifier on local
> classes.
>
> From a hierarchy-protection point of view, allowing local classes to be
> `sealed` is also silly, as it cannot be extended from outside the method
> a
No need. Varargs-ness is reified with the (mandated) canonical ctor.
On 10/11/2019 4:43 PM, Remi Forax wrote:
It seems we have to add an access_flag for each record component because we
have to mark if the record component is a varargs or not.
So the format should be
Record_attribute {
u2
It seems we have to add an access_flag for each record component because we
have to mark if the record component is a varargs or not.
So the format should be
Record_attribute {
u2 attribute_name_index;
u4 attribute_length;
u2 number_of_record_components;
{ u2 component_access_flags;
Hi Johnathan,
as others said, i find the javadoc very clear.
Minor nits, for equals:
"Indicates whether some other object is "equal to" this one. The objects are
equal if the other object is of the same class and if all the record components
are equal. All components are compared with '=='."
I've added two new examples, for a serializable record
(SerializablePoint) and a serializable type with a record for a
serialization proxy (SerializableProxy): the name for that one is
intended to be description of the example, although admittedly, it is
not a particularly good name for the fun
On 10/11/19 3:48 AM, Maurizio Cimadamore wrote:
On records, what you did looks, again, very clean. The only comment I
have there is that it "feels" like something is missing in the summary
section... e.g. for some reason I would expect a "record components
summary" there. I noted that you l
Hello,
Some modifiers are implementation properties, like strictfp, native, and
synchronized -- they not part of the "interface" of the method per se,
but still useful to apply and query in some circumstances. The
"mandated" property can have a similar character as partially a function
of th
On 11/10/2019 15:11, Brian Goetz wrote:
On records, what you did looks, again, very clean. The only comment I
have there is that it "feels" like something is missing in the
summary section... e.g. for some reason I would expect a "record
components summary" there. I noted that you lifted th
Noted. But I also note we suppress always-on modifiers for other
elements :-) So I guess we choose on a case-by-case basis.
FWIW, javadoc is driven by the Language Model (javax.lang.model) API,
and not what is in the source code.
-- Jon
On 10/11/19 8:43 AM, Brian Goetz wrote:
I think it w
I think it would be good if the javadoc always said “final” for records,
regardless of what was in the source.
> On Oct 11, 2019, at 11:37 AM, Chris Hegarty wrote:
>
> Jon,
>
> The javadoc looks great.
>
> I’m sure that this has come up already, but I cannot find it, so I’ll ask
> here.
>
Jon,
The javadoc looks great.
I’m sure that this has come up already, but I cannot find it, so I’ll ask here.
Should the javadoc include the fact that a record class is `final`? Or is that
implied by the fact that it is a record?
The reason I ask is that one can write `public final record R {}
> On records, what you did looks, again, very clean. The only comment I have
> there is that it "feels" like something is missing in the summary section...
> e.g. for some reason I would expect a "record components summary" there. I
> noted that you lifted the components to the toplevel doc, but
This seems reasonable to me. So, spec consequences:
- sealed, non-sealed illegal on enums
- enums can implement sealed types
- said permission to extend pushes down to constants, including the anonymous
classes of nontrivial constants
> On Oct 11, 2019, at 6:59 AM, Maurizio Cimadamore
>
- Mail original -
> De: "Maurizio Cimadamore"
> À: "Tagir Valeev"
> Cc: "amber-spec-experts"
> Envoyé: Vendredi 11 Octobre 2019 12:59:41
> Objet: Re: [sealed] Sealed local classes?
> I think an enum declaration is 'morally final' in the sense that, while
> it can't really be marked with
I think an enum declaration is 'morally final' in the sense that, while
it can't really be marked with ACC_FINAL (because there might be
constants which extend from it), the user cannot subclass the enum.
Everything weird you can do with an enum, remains _inside_ the enum
declaration bubble, wh
I think the output looks very clean. On the 'sealed' part I have no
objectctions.
On records, what you did looks, again, very clean. The only comment I
have there is that it "feels" like something is missing in the summary
section... e.g. for some reason I would expect a "record components
su
Brian, Peter,
On 09/10/2019 19:52, Brian Goetz wrote:
> ...
> I think there is room to support the future. Here are some ways we could
> extract the state from a record for serialization:
> A. Scrape the fields.
> B. Call the field accessors.
> C. Invoke the canonical deconstructor (when we h
20 matches
Mail list logo
