<div dir="ltr"><div style="font-family:monospace" class="gmail_default">Hello Brian,<br><br>Thank you for the response!<br><br>> Thanks for the nice success story and the kind words.  A<br>> few comments:<br>> <br>> > Since all elements of this structure were either<br>> > sealed, a record, or an enum, that meant that my<br>> > domain of possible types (and thus, solutions) was very<br>> > bounded. That boundedness made reasoning about my<br>> > domain much easier.<br>> <br>> This is the power of "make illegal states<br>> unrepresentable".  By using the type system to represent<br>> only the valid states of your domain, code can focus on<br>> the happy path.<br><br>I see what you mean now. Yes, now that I think about it, exception cases and trying to keep all the logic in my head was really me trying to juggle too many unhappy paths, bogging down my development efforts until I am just spinning my wheels. Having the weight off of my shoulders allows me to move and think more freely and creatively. To my understanding, the ability to "make illegal states unrepresentable" comes from the fact that Java now has Abstract Data Types. That makes ADT's very powerful and something I should start defaulting to when the situation allows it to, so that I can get all of this freedom and ease of movement.<br><br>As for the rest of your response, I'll just address it all in total without quoting.<br><br>Yes, I definitely agree. Without pattern-matching/Data-Oriented-Programming/ADT's, even the pain points I mentioned would be far worse. In fact, prior to using Amber features, I was in the camp of using solutions 1 and 2 exclusively, since 3 was just too complex and error prone to maintain in the face of refactoring or changing requirements. It's only because of the thus far released features that 3 even became an option for me at all.<br><br>I am very excited for what this future with pattern-matching looks like. In my previous attempt [1], I went down the painstaking route of getting my data into fully strongly typed objects, so I paid the full price of translation, as mentioned in the link. And I did exactly like you said in my previous attempt -- I ended up with this >60 line mess of trying to turn untyped data into typed data [2].<br><br>Can you give me a tiny snippet of what that future might look like? You mentioned composing, and that makes a lot of sense, but I was curious about what the things we are composing look like. You say we are composing pattern matching. You mentioned matching the String in your example, `"x":"3"`. I used an ugly java.util.regex.Pattern to handle a String of a similar format in my previous attempt [3]. What might the future look like when pattern matching that `"x":"3"`? I see that java.util.regex.Pattern introduces sort of a second class citizen version of pattern matching right now. You use Pattern::matcher to test for a match. And the only way to extract the successful match is to call the Matcher::matches method first, then extract. Java will return a failure if you do not call this first, allowing essentially the same functionality that pattern matching gives you. Are we going to see a more condensed and first class version of this when turning Stringly-typed data into strongly typed data? And if so, what's your guess of what that would look like?<br><br>Thank you for your time and insight!<br>David Alayachew<br><br>[1]=<a href="https://mail.openjdk.org/pipermail/amber-dev/2022-September/007456.html">https://mail.openjdk.org/pipermail/amber-dev/2022-September/007456.html</a><br>[2]=<a href="https://github.com/davidalayachew/RulesEngine/blob/main/src/main/java/io/github/davidalayachew/ClassParser.java#L22">https://github.com/davidalayachew/RulesEngine/blob/main/src/main/java/io/github/davidalayachew/ClassParser.java#L22</a><br>[3]=<a href="https://github.com/davidalayachew/RulesEngine/blob/main/src/main/java/io/github/davidalayachew/IsIdentifierAType.java#L9">https://github.com/davidalayachew/RulesEngine/blob/main/src/main/java/io/github/davidalayachew/IsIdentifierAType.java#L9</a><br></div><br></div>