Constructing records through reflection and module restrictions

[Florian Weimer]

* Brian Goetz:

> On 12/7/2024 3:35 PM, Florian Weimer wrote:
>> * Brian Goetz:
>>
>>> Let’s take about 100 steps back. Why do you think that records
>>> should be immune to the ordinary access control of the language?
>> I think of them of named tuples.  Tuples don't have this type of
>> access control.  But of course, one could argue that once names are
>> involved, the matter of access control arises.  I had not considered
>> this.
>
> And further, records are _classes_.  They have some extra specification 
> (which comes from java.lang.Record), and some special syntax, but like 
> enums, they boil down to ordinary classes. Further^2, it should be 
> possible to compatibly migrate between classes and records (as you can 
> with enums) if you reach the limits of what records (enums) can do.  So 
> it would be very weird to have them be magically transparent.

On the other hand, enums do have a bypass for certain member accesses.
And this isn't something you can emulate after turning an enum into a
less-constrained class.

>> For example, to read a CSV file with two colums, something like this
>> could be used:
>>
>>              record Row(String name, int index) {}
>
> Sure, but what is stopping you from making Row public/exported, if 
> that's the case?  There's nothing private or secret about it.

It's the syntactic overhead.  The attractiveness of this pattern is
that's it's a clear and concise notation for this type of
deserialization.  Creating a public type for it in a suitable package
sort of breaks that.