Data Oriented Programming, Beyond Records

[Brian Goetz]

First, a gentle reminder that I did ask "please, let's not discuss 
syntax."  It is way too early for that; we haven't even had a discussion 
on the value of the ideas yet.  But people can't help but obsess on 
syntax, so I'll answer, but please let's let this thread end here.

Yes, we considered matching on name and type only.  There is nothing 
about that approach that makes it unworkable, but it is less reliable, 
and subjectively, seems to be more likely to feel "magic" or "action at 
a distance" to the Java developers we showed this to.  By comparison, 
the overhead of the `component` modifier is small; it is purely 
horizontal rather than vertical, and admits no question about which 
fields are component fields or not.  It also admits greater flexibility 
for users (under the implicit approach, we'd almost certainly want to 
error out if the names matched but the types didn't; with the explicit 
version, we can accept examples like the AlmostRecord in the writeup.)

Basically: the value of the clarity seems to outweigh the value of the 
concision.  )(And, as you point out, a new modifier would still be 
needed for "not component" in that case.)


On 1/13/2026 10:25 PM, Ganapathi Vara Prasad wrote:
> Hello Brian,
>
> Thank you for thinking on this feature. I want to better understand 
> the thought process behind marking all fields that are part of the 
> component state instead of only the derived fields. Something like this:
>
> ```
> class Point(int x, int y) {
>       private final int x;
>       private final int y;
>       private final derived double norm;
>
>       Point {
>           norm = Math.hypot(x, y);
>       }
>
>       public double norm() { return norm; }
>
>       // derived implementation of x and y accessors
>       // derived implementation of equals, hashCode, toString
> }
> ```
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260113/fb97af72/attachment-0001.htm>