Allowing inheritance with Records?

[Vikram Bakshi]

> I almost spill my tea :)

:)

> Inheritance is about sharing behaviors, so the data behaviors should not
change too much. But business requirement, business data/computation
changes are frequent, so using inheritance is a kind of an an anti-pattern
for data.

Is it really an anti-pattern in all situations though? There have been
times where I have wanted my record to inherit from a record representing
some "id" which itself contains methods/behaviour. I can think of it being
useful in some situations.

> It's far far easier to use records, empty interfaces and pattern matching
(switch on types) when you want to define data and their business rules
than tryig to use inheritance for a case it will not work well.

I think allowing the developer the flexibility to choose whether or not
they would like inheritance would still be a valid "Java" way of doing
things.

I understand from Brian's email that record inheritance is currently
shelved so we will have to wait and see if it ever becomes a priority
(other upcoming features like the "state monad" for records are probably
more important anyway
https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md
).

Regards,
Vikram










On Fri, Dec 29, 2023 at 2:05 PM Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Vikram Bakshi" <vab2048 at gmail.com>
> *To: *amber-dev at openjdk.java.net
> *Sent: *Thursday, December 28, 2023 3:59:10 PM
> *Subject: *Allowing inheritance with Records?
>
> Hello,
>
> Is the decision to not allow inheritance for records set in stone? Or will
> this be opened up and explored in the future?
>
> One of the goals of records (from Brian Goetz Devoxx talk) is to "model
> data as data", and allowing inheritance would offer a powerful way of
> modelling data.
>
>
> I almost spill my tea :)
> Inheritance is about sharing behaviors, so the data behaviors should not
> change too much. But business requirement, business data/computation
> changes are frequent, so using inheritance is a kind of an an anti-pattern
> for data.
>
> It's far far easier to use records, empty interfaces and pattern matching
> (switch on types) when you want to define data and their business rules
> than tryig to use inheritance for a case it will not work well.
>
>
>
> Right now we have to write interfaces for fields which are shared/static
> methods for shared behaviour/copying and pasting - which I do not think is
> ideal.
>
> Regards,
> Vikram
>
>
> regards,
> Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240105/1b71a89c/attachment.htm>