[records] updates for Preview 6. Default access modes

John Rose john.r.rose at oracle.com
Fri Jan 10 06:40:01 UTC 2020


6. Default access modes in records.  (See above. )

I specifically want to make sure we are doing the best thing on
access defaults (what happens when you don’t mention *any*
access mode).  I suppose that’s a separate item, related to this
one.  Even though we have a decision of record on this, I’m
calling it out here and now because we are stuck with the final
decision we make this time around.  (Maybe like a mandatory
appeal for a capital case.)

Choices:  A. Package scope like classes, B. public like interfaces,
C,D,… something new for records.

A. Records are concise classes which represent a state vector
of components, plus optional additional behavior.  If a record
member is declared with no access mode, it is given the package
access mode.  Just like classes.  The word “public” must be
reaffirmed for every API in the record; just like classes, the
presumption is that API points should be private by default,
and only made public via explicit mark-up.

B. Records are state vectors of components, plus optional
additional behavior.  They are not general classes, but rather
constrained types, much like interfaces are behavior vectors
of abstract API points, plus optional behavior.  If a record
member is declared with no access mode, it is given the
public access mode.  Just like an interface, a record is a
restricted type, whose contracts with the outside world
are mainly public, and which has a limited capacity for
non-public contracts.

C. Records are state vectors of components, plus optional
additional behavior.  The parts of their API which are
intended to be mostly public are public by default, at least
if the record type as a whole is public.  The precedent for
this variability is the implicit empty nullary constructor
supplied to every class, whose access mode is copied
from the class itself.  The parts of a record API that are
expected to be public are the factory (canonical constructor)
and the accessors (component projection methods).
So those guys are public by default (if the record is public).
(If the record isn’t public those other guys are the same.)

At present I prefer “B”, because I now think that, regarding
the access expectiations of API points, records are *far more
similar to interfaces* than they are to random run of the mill
classes.  We started with random classes, but after applying
enough constraints we now have API elements which are
closely analogous to interfaces:  Bundles of state, bundles
of operations.  And, for wide use; i.e. few or no secrets.
In both cases, “public” is the sane default.

An advantage of “B” is there’s nothing new to teach. “You
know how interfaces have their own default access?  Well,
records use the same rules.”

— John


More information about the amber-spec-experts mailing list