----- Mail original ----- > De: "Tagir Valeev" <amae...@gmail.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Vendredi 10 Janvier 2020 11:04:42 > Objet: Re: [records] updates for Preview 6. Default access modes
> I don't like B. The problem with B is that having a public default you > may mistakenly expose an implementation detail, and it could be hard > to fix this when clients start to use it. With interface methods this > is less important, because if you have an implementation inside > interface, you should explicitly mark it with either 'default' > (meaning that it's still part of an interface) or 'private' (meaning > that it's an implementation detail). But specifying an interface > method with a body without a modifier at all is an error, so you will > have to think. Records are not of this kind. They are not abstract, > every method has an implementation, and it's perfectly valid to add a > method without specifying any modifier. You will have all the tests > passing, etc., but you're still doing a mistake, which is expensive to > fix. > > Of these options, I like C the most, though I would modify it: > D. The access modifier for explicit overloads to synthetic members > (canonical constructor & accessors) must be the same or more > permissive than an access modifier for the record itself. The absence > of access modifier means 'package-private', as usual for classes. This > would require 'public' for public records, and it's nice because you > will see that it's really a part of the API. On the other hand, this > would reduce noise for inner/local records where you can omit the > access modifier. And still, you can specify public on local records, > so you can easily reduce the record visibility without the need to > modify all the members. yes, i vote for D too. I really dislike the noise, i.e. to have to write public in front of an accessor or a compact constructor when the whole record is declared private just above. > > Adding an explicit package/non-public modifier is a good idea per se, > but it's orthogonal to the records case. We can implement it (allowing > package-private members in interfaces), yet stick with my D proposal. > > With best regards, > Tagir Valeev. Rémi > > On Fri, Jan 10, 2020 at 1:52 PM John Rose <john.r.r...@oracle.com> wrote: >> >> P.S. The alert reader has perhaps already said, “but wait, if you >> make records like interfaces, then records cannot define non-public >> APIs!” Very good, alert reader, that’s just like interfaces. And we >> can amend *both* by adding some way to overcome the default >> “public” with a new modifier that means “I know you default to >> public, and I know the normal syntax for package access is to >> say nothing and obtain a different default, and I want that package >> access, please.” Potential spellings for that modifier are “package” >> and “non-public”. >> >> In interfaces, haven’t you ever wanted to define a non-public nested >> class which implements the interface or carries some other interesting >> implementation data? The JVM has no objection to you doing so, but >> the language does. It would be helpful to allow an interface to define >> a non-public nested class, for the sake of modularity. The “package” >> or “non-public” modifier would support this. >> >> Even for garden variety classes there’s a use case for such a modifier. >> Haven’t you ever wanted to mark an API point, “don’t make this public, >> for heaven’s sake”? I use the comment “/*non-public*/” which drives >> maintainers crazy. Saying “non-public” or “package” would be a better >> way to document the intention.
