[records] updates for Preview 6. Default access modes

[Remi Forax]

----- Mail original -----
> De: "Tagir Valeev" <amaembo at gmail.com>
> Cc: "amber-spec-experts" <amber-spec-experts at 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.rose at 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.