It's the data, stupid !

[Brian Goetz]

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>