Re: Draft JLS spec for records - local types

> Sorry, I know I’ve said this before, but I guess not on this thread. Local > records are always implicitly static — they cannot capture anything. (Local > enums would be the same way.) As you point out, the hidden state would > undermine the “the record description is the state, the whole s

Re: Draft JLS spec for records - local types

Sorry, I know I’ve said this before, but I guess not on this thread. Local records are always implicitly static — they cannot capture anything. (Local enums would be the same way.) As you point out, the hidden state would undermine the “the record description is the state, the whole state, an

Re: Draft JLS spec for records - local types

Hello! > Local records should be allowed; we should probably allow local enums at the > same time. On the other hand, local classes also may have an implicit state which consists of captured variables and possibly captured `this` reference as well. Usually, all instances of local classes that ca

Re: Draft JLS spec for records - local types

- Mail original - > De: "Brian Goetz" > À: "Peter Levart" > Cc: "amber-spec-experts" > Envoyé: Dimanche 6 Octobre 2019 17:06:14 > Objet: Re: Draft JLS spec for records - local types >> When reading the spec, the following cau

Re: Draft JLS spec for records - local types

> When reading the spec, the following caught my attention: > > """A nested record type is implicitly static. It is permitted for the > declaration of a nested record type to redundantly specify the static > modifier. > >This implies that it is impossible to declare a record type in the bod

Re: Draft JLS spec for records - local types

On Friday, August 23, 2019 11:25:05 PM CEST Gavin Bierman wrote: > A draft language spec for records is available at: > > http://cr.openjdk.java.net/~gbierman/8222777/8222777-20190823/specs/records-> > jls.html Hi Gavin, When reading the spec, the following caught my attention: """A nested rec

Re: Draft JLS spec for records

- Mail original - > De: "Brian Goetz" > À: "Remi Forax" > Cc: "John Rose" , "amber-spec-experts" > > Envoyé: Vendredi 6 Septembre 2019 00:29:14 > Objet: Re: Draft JLS spec for records >> from the same mail: >>

Re: Draft JLS spec for records

from the same mail: "the canonical constructor should follow the same rule as the default constructor". This isn't an obviously terrible idea, but it's also not a very important distinction, because the difference isn't observable -- if the class isn't accessible to the caller, they still

Re: Draft JLS spec for records

- Mail original - > De: "Brian Goetz" > À: "Remi Forax" > Cc: "John Rose" , "amber-spec-experts" > > Envoyé: Jeudi 5 Septembre 2019 23:48:08 > Objet: Re: Draft JLS spec for records >> It's not what i'm saying. &

Re: Draft JLS spec for records

fo...@univ-mlv.fr wrote: - Mail original - De: "Brian Goetz" À: "Remi Forax" Cc: "John Rose" , "amber-spec-experts" Envoyé: Jeudi 5 Septembre 2019 22:55:13 Objet: Re: Draft JLS spec for records We are circulating back to my first question, why

Re: Draft JLS spec for records

It's not what i'm saying. Maybe you could tell us what you are saying?

Re: Draft JLS spec for records

- Mail original - > De: "Brian Goetz" > À: "Remi Forax" > Cc: "John Rose" , "amber-spec-experts" > > Envoyé: Jeudi 5 Septembre 2019 22:55:13 > Objet: Re: Draft JLS spec for records >> >> We are circulat

Re: Draft JLS spec for records

I don't think so. A compact constructor (or require initializer, as you propose) could be not the only constructor. An instance initializer is convenient because it's added to every constructor, regardless of whether it's compact or not. So the new thing doesn't supersede the instance initi

Re: Draft JLS spec for records

We are circulating back to my first question, why the constructor has to be public. Think about it some more.  Suppose the default was that the constructor was private.  Now, without specifying a constructor, no record could be instantiated at all, without the user declaring a construct

Re: Draft JLS spec for records

> De: "Brian Goetz" > À: "Remi Forax" > Cc: "John Rose" , "amber-spec-experts" > > Envoyé: Jeudi 5 Septembre 2019 21:24:55 > Objet: Re: Draft JLS spec for records [...] >> But i don't think it's a good idea to make al

Re: Draft JLS spec for records

There needs to be a deterministic, mechanically-derivable-from-the-state-vector way to construct a record instance.  Serialization, for example, would use this for reconstructing the object; frameworks like O/R mappers would do the same.  Allowing the user to withdraw the co

Re: Draft JLS spec for records

> De: "Brian Goetz" > À: "Remi Forax" > Cc: "John Rose" , "amber-spec-experts" > > Envoyé: Jeudi 5 Septembre 2019 15:49:25 > Objet: Re: Draft JLS spec for records >> can someone explain me why we need the constructor to be public

Re: Draft JLS spec for records

> can someone explain me why we need the constructor to be public ? The essence of records is: “the author gives up the right to decouple the public API from the representation.” That means that the construction, deconstruction, access, equality, hashing, and textualization protocols are deriv

Re: Draft JLS spec for records

- Mail original - > De: "John Rose" > À: "Remi Forax" > Cc: "Gavin Bierman" , "amber-spec-experts" > > Envoyé: Jeudi 5 Septembre 2019 01:27:23 > Objet: Re: Draft JLS spec for records > On Sep 3, 2019, at 5:02 AM, fo

Re: Draft JLS spec for records

> De: "Brian Goetz" > À: "Remi Forax" , "Tagir Valeev" > Cc: "amber-spec-experts" > Envoyé: Jeudi 5 Septembre 2019 00:05:18 > Objet: Re: Draft JLS spec for records > Ideally, records are classes, with restrictions (like enums). And agai

Re: Draft JLS spec for records

On Sep 3, 2019, at 5:02 AM, fo...@univ-mlv.fr wrote: > > Given that i've always find the syntax of the canonical constructor too close > to the one of the real constructor (depending on the fact that parenthesis > are present or not), > i propose a new kind of initializer, the require initialize

Re: Draft JLS spec for records

On Sep 3, 2019, at 10:21 PM, Tagir Valeev wrote: > > I don't think so. A compact constructor (or require initializer, as you > propose) could be not the only constructor. An instance initializer is > convenient because it's added to every constructor, regardless of whether > it's compact or no

Re: Draft JLS spec for records

> De: "Tagir Valeev" > À: "Remi Forax" > Cc: "Gavin Bierman" , "amber-spec-experts" > > Envoyé: Mercredi 4 Septembre 2019 07:21:48 > Objet: Re: Draft JLS spec for records > Hello! Hi ! >> I also believe we should make the

Re: Draft JLS spec for records

x" *Cc: *"Gavin Bierman" , "amber-spec-experts" *Envoyé: *Mercredi 4 Septembre 2019 07:21:48 *Objet: *Re: Draft JLS spec for records Hello! Hi ! > I also believe we should make the instance initializer illegal in record given that a re

Re: Draft JLS spec for records

On 03/09/2019 22:00, Alex Buckley wrote: The private fields aren't synthetic (generated by a compiler as a private implementation detail), they're mandated ("implicitly declared"). 8.10.3 says that the implicitly declared fields have the annos from the components, great, done. You are righ

Re: Draft JLS spec for records

Valeev. On Tue, Sep 3, 2019 at 7:02 PM wrote: > > > -- > > *De: *"Gavin Bierman" > *À: *"Remi Forax" > *Cc: *"Brian Goetz" , "amber-spec-experts" < > amber-spec-experts@openjdk.java.net> > *Envo

Re: Draft JLS spec for records

Let me comment on Maurizio's comments, and add some more. In 1.1, the spec for enum types has been used as a template, which is fine, but the summary of enum types has always been poor: the singular/plural construction is weird, and the mixing of kinds (class v. object) is horrible. The JLS is

Re: Draft JLS spec for records

Nits * in 8.10.1: "Each record component in the /RecordHeader/ declares one |private final| field in the record class whose name is same as the /Identifier/ in the record component." This seems a bit early. Also, you repeat the same in 8.10.3, which is arguably a much better place? * Also

Re: Draft JLS spec for records

> De: "Gavin Bierman" > À: "Remi Forax" > Cc: "Brian Goetz" , "amber-spec-experts" > > Envoyé: Mardi 3 Septembre 2019 12:37:17 > Objet: Re: Draft JLS spec for records > Thanks Remi. >> - a canonical constructor can not have

Re: Draft JLS spec for records

Thanks Remi. > - a canonical constructor can not have throws clause (from the text of the > section) but the grammar in 8.10.2 the CompactConstructor declaration can > have a throw clause ? That is just a typo - thanks. The rest I will get back to you shortly. Thanks, Gavin

Re: Draft JLS spec for records

gt; De: "Gavin Bierman" > À: "amber-spec-experts" > Envoyé: Vendredi 23 Août 2019 23:25:05 > Objet: Draft JLS spec for records > A draft language spec for records is available at: > [ > http://cr.openjdk.java.net/~gbierman/8222777/8222777-20190823/specs/r

Re: Draft JLS spec for records

Added. > On 26 Aug 2019, at 16:25, Brian Goetz wrote: > >> The listing of serialPersistentFields seems fine too, again possible >> collision with the record component field. >> >> serialVersionUID is static, so doesn't need to need to be listed. Ok. > > You can’t have two fields with the sam

Re: Draft JLS spec for records

Thanks Chris! > On 26 Aug 2019, at 14:43, Chris Hegarty wrote: > > Gavin, > > On 23/08/2019 22:25, Gavin Bierman wrote: >> A draft language spec for records is available at: >> http://cr.openjdk.java.net/~gbierman/8222777/8222777-20190823/specs/records-jls.html >> ... > > > "It is a compile-t

Re: Draft JLS spec for records

>> >> Does "formal parameter list" include the component name ( as well as the >> order and type )? > > yes the canonical constructor has to match on component names too, I suspect this is one of the areas where the implementation and the spec don’t yet agree, so it is a good chance to discuss

Re: Draft JLS spec for records

> The listing of serialPersistentFields seems fine too, again possible > collision with the record component field. > > serialVersionUID is static, so doesn't need to need to be listed. Ok. You can’t have two fields with the same name, even if one is static and the other is not. So sVUID should

Re: Draft JLS spec for records

On 8/26/19 10:03 AM, Chris Hegarty wrote: Gavin, On 23/08/2019 22:25, Gavin Bierman wrote: A draft language spec for records is available at: http://cr.openjdk.java.net/~gbierman/8222777/8222777-20190823/specs/records-jls.h "8.10.4 Record Constructor Declarations  Every record type R h

Re: Draft JLS spec for records

Gavin, On 23/08/2019 22:25, Gavin Bierman wrote: A draft language spec for records is available at: http://cr.openjdk.java.net/~gbierman/8222777/8222777-20190823/specs/records-jls.h "8.10.4 Record Constructor Declarations Every record type R has a canonical constructor. This is a public co

Re: Draft JLS spec for records

Gavin, On 23/08/2019 22:25, Gavin Bierman wrote: A draft language spec for records is available at: http://cr.openjdk.java.net/~gbierman/8222777/8222777-20190823/specs/records-jls.html ... "It is a compile-time error for a record header to declare a record component with the name clone, fin

Draft JLS spec for records

A draft language spec for records is available at: http://cr.openjdk.java.net/~gbierman/8222777/8222777-20190823/specs/records-jls.html This spec doesn’t yet discuss varargs records - to appear in the next dr