It's the data, stupid !

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Sent: Monday, May 30, 2022 4:31:19 PM
> Subject: Re: It's the data, stupid !

> 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?
First, i've overlook the importance of the record pattern as a check of the shape of the data. 

Then if we say that data are more important than code and that the aim of the pattern matching is to detect changes of the shapes of the data, 
it changes the usefulness of some features/patterns. 

it makes the varargs pattern a kind of harmful, because it matches data of several shapes, so the code may still compile if the shape of the record/data-type change. 
Given that we have already establish that 
- the varargs pattern can be emulated by an array pattern and it's even better because an array pattern checks that the shape is an array and 
- the varargs is dangerous because record with varargs are hard to get right. 

The result is that i'm not sure the vararg pattern is a target worth pursuing. 

Deconstructors of a class also becomes a kind of a war ground between the OOP and the pattern matching, OOP says that API is important and pattern matching says it's ok to change the data changing the API because the compiler will points where the code should be updated. 
We still want encapsulation because it's a class but we want to detect if its shape change so having a class with several shapes becomes not as useful as i first envision. 

And we have some pattern methods, that works more like extension methods because you can define them outside of the class you do the matching on (they are not instance pattern method) and how those are supposed to work when a shape is updated. 

Rémi 

> 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/7f2cab9a/attachment-0001.htm>