Data Oriented Programming, Beyond Records

[Ganapathi Vara Prasad]

Hi Brian,

I might have worded question incorrectly, but it was about the idea of
marking (which we need) on component vs derived fields. Why would we choose
one over the other irrespective of the syntax used to achieve that?

I still need to understand your response, but thanks for the response.

On Wed, 14 Jan, 2026, 9:14 am Brian Goetz, <brian.goetz at oracle.com> wrote:

> 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/20260114/e6298ef6/attachment.htm>