<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">Thanks for the nice success
story and the kind words. A few comments:<br>
<br>
<blockquote type="cite">Since all elements of this structure
were either sealed, a record, or an enum, that meant that my
domain of possible types (and thus, solutions) was very
bounded. That boundedness made reasoning about my domain much
easier.</blockquote>
<br>
This is the power of "make illegal states unrepresentable". By
using the type system to represent only the valid states of your
domain, code can focus on the happy path. <br>
<br>
I want to dig a little into the one "still could be improved"
comment:<br>
</font></font><br>
<blockquote type="cite" cite="mid:CAA9v-_Mi6SnC6q1nZWQkrm2=UDDEJq5B1aD94Nvhxyju0UQ7BA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_default" style="font-family:monospace">*
Converting untyped data into typed data still feels
frustrating and difficult. I was able to bypass most of it
this time around because, thankfully, this project had very
little conversion (whereas my previous project [2] was
completely built around that concept)<br>
</div>
</div>
</blockquote>
<font size="4"><font face="monospace"><br>
Indeed, there is more to go here. The good news is that this
challenge is a big part of why we embarked on the pattern
matching story in the first place. We've gotten far enough on
this story that it has enabled some of the things you talk
about, but we still have a ways to go. <br>
<br>
Untyped data is a fact of life; Java is not a bubble, and we
will always be dealing with unstructured user input, untyped
documents like JSON, or typed data from another type system,
such as SQL result sets or XML which rigorously uses schema to
enforce types. Even if an XSD tells us that a given element or
attribute is of type `xsd:integer`, that doesn't mean "signed 32
bit int". And as program units get "smaller" (break up them
monoliths), all the code gets "closer to the boundary", and at
the boundary, things are untyped.<br>
<br>
There are several approaches to untyped data taken by Java
programs, all of which are pretty limited:<br>
<br>
- Deal with it directly as untyped data. This makes our Java
programs stringly typed.<br>
<br>
- Try to map it automatically via ORMs, JAXB, and similar data
binding mechanisms. This is practical for semi-typed data, but
often runs out of gas before we're done.<br>
<br>
- Painstakingly unpack it into Java data using imperative tools
like JSON-P. This typically results in large masses of
error-prone and brittle code (Does it have a key called X? Is
that key mapped to an integer? Is that integer within range of
`int`?). It is not uncommon to see 50-100 lines of awful
"unpacking" code followed by a few lines of clean "business
logic" and then some more "repacking code". This often makes me
wonder "Where's the Beef?" <br>
<br>
To deal with untyped data, we need an organized way to define
the boundary. To avoid descending into a rat's nest of horrible
imperative checks like the third solution, our boundary
management tools need to *compose*. <br>
<br>
Pattern matching composes. If I'm trying to match `"x": "3"` to
extract the int value, I need a way to express "key X", "maps to
double", "double can be converted to int" in a single go, not
treat it as three separate sources of error, and ignore the
parts of the structure I am not interested in. The key thing
the language was missing to get there was a flexible,
composable, fused test-and-conditionally-extract operation.
More to come!<br>
</font></font>
</body>
</html>