It's the data, stupid !
Brian Goetz
brian.goetz at oracle.com
Mon May 30 14:31:19 UTC 2022
Indeed, this is a big part of the motivation. And it's not just pattern
matching; its the combination of records (representing data as data),
sealed classes (the other half of algebraic data types, enabling richer
data-as-data descriptions), and pattern matching (ad-hoc polymorphism,
great for data). The catchphrase we've been using in last few years has
been make it easier to do "data-oriented programming" in Java. This
isn't a departure from OO, it's a recognition that not everything is
best modeled as an stateful entity that communicates by sending and
receiving messages.
Rolling back to the origin of these feature set (several years ago at
this point), we observed that programs are getting smaller; monoliths
give way to smaller services. And the smaller the unit of code is, the
closer it is to the boundary, at which it is exchanging messy untyped
(or differently typed) data with the messy real world -- JSON, database
result sets, etc. (Gone are the days where it was Java objects all the
way down, including across the wire boundary.) We needed a simpler way
to represent strongly typed ad-hoc data in Java, one that is easy to
use, which can be easily mapped to and from the external messy formats
at the boundary. OO is great at defining and defending boundaries (it
totally shines at platform libraries), but when it comes to modeling
ordinary data, costs just as much but offers us less in return. And
pattern matching is key to being able to easily act on that data, take
it apart, put it back together differently, etc. The future
installments of pattern matching are aimed at simplifying the code at
that boundary; using pattern matching to mediate conversion from
untyped, schema-free envelopes like JSON to
illegal-states-are-unrepresentable data.
So, yes: records + sealed classes + pattern matching = embracing data as
data. I've got a piece I've been writing on this very topic, I'll send
a link when its up.
And yes, we've been talking a lot about the details, because that's what
this group is for. But I don't think we have lost sight of the big
picture.
Is there something you think we've missed?
On 5/30/2022 8:33 AM, Remi Forax wrote:
> Hi all,
> i think the recent discussions about the pattern matching are too much about details of implementation and i fear we are losing the big picture, so let me explain why i (we ?) want to add pattern matching to Java.
>
> Java roots is OOP, encapsulation serves us well for the last 25+ years, it emphasis API above everything else, data are not important because it's just a possible implementation of the API.
>
> But OOP / encapsulation is really important for libraries, less for applications. For an application, data are more important, or at least as important as API.
>
> The goal of pattern matching is make data the center of the universe. Data are more important than code, if the data change because the business requirements change, the code should be updated accordingly. Pattern matching allows to write code depending on the data and it will fail to compile if the data change, indicating every places in the code where the code needs to be updated to take care of the new data shape.
>
> The data can change in different ways,
> 1) a new kind of a type (a subtype of an interface) can be introduced, we have added sealed types and make switch on type exhaustive so if a developer add a new subtype of an interface, the compiler will refuse to compile all patterns that are not exhaustive anymore, indicating that the code must be updated.
> 2) a data can have a new field/component, we have introduced record pattern that match the exact shape of a record, so if a developer add a new component, the compiler will refuse to compile the record pattern with a wrong shape indicating that the code must be updated.
>
> So experts, do you agree that this is what we want or did i miss something ?
>
> Rémi
>
> PS: the title is a nod to James Carville.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220530/8be79846/attachment.htm>
More information about the amber-spec-experts
mailing list