<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">Let's step back, because your
question is caught up in the details of a solution, rather than
focusing on the problem.<br>
<br>
Obviously we want to be able to pattern match on Optional. You've
gone down the road of "We have pattern matching for ADTs, so let's
turn Optional into an ADT, and then pattern match on that", and
then got caught in the details of whether this is a compatible
refactoring.<br>
<br>
But I don't think we have to, or should, refactor the
representation to "match" the pattern machinery. As outlined in
"Towards Member Patterns" and "Patterns in the Object Model", we
want to use the same tools for destructuring as we do for
aggregation. Optional is assembled with static factories; we
should be able to take it apart with static patterns:<br>
<br>
switch (o) { <br>
case Optional.of(var e): ...<br>
case Optional.empty(): ...<br>
}<br>
<br>
Adding `Some` and `None` deconstruction patterns would work, but
then we lose the correspondence between "how we put it together"
and "how we take it apart." So I don't want to go down this
road. (Another reason to not go down this road is that we want
Optional to work as a value type, which means one
implementation.) <br>
<br>
There are a few details yet to be wrapped up (e.g., how do we
denote the of/empty pair as exhaustive).<br>
</font><br>
<div class="moz-cite-prefix">On 1/26/2024 2:30 AM, Red IO wrote:<br>
</div>
<blockquote type="cite" cite="mid:CABKyW1sFz45a2NheeyJ1a99YmoAeCOgqBLGZg6=y=udzVQsiUA@mail.gmail.com">
<div dir="auto">Now that pattern matching is nearly complete I was
thinking about the distinction how the option type of the jdk
works.
<div dir="auto">What I'm talking about is the split between
checking if it's empty and retrieving the value.</div>
<div dir="auto">Sure there are ways to transform the optional
and GetOrElse and Throw varients. But none of them express the
connection between isPresent and get:</div>
<div dir="auto">var option = Optional.of("Foo");</div>
<div dir="auto">if (option.isPresent()) {</div>
<div dir="auto"><span style="white-space:pre"> </span>var foo =
option.get(); </div>
<div dir="auto">} </div>
<div dir="auto">Now pattern matching comes into play. A great
solution that is used by many other languages to deal with the
option type is matching rather or not it's present and in the
same step providing the value to the valid code block.
Something like this:</div>
<div dir="auto">var option = Optional.of("Foo");</div>
<div dir="auto">switch(option) {</div>
<div dir="auto"><span style="white-space:pre"> </span>case
Some(foo) -> {} </div>
<div dir="auto"><span style="white-space:pre"> </span>case
None() -> {} </div>
<div dir="auto">} </div>
<div dir="auto">Or </div>
<div dir="auto">if(option instanceof Some(foo) {</div>
<div dir="auto"><br>
</div>
<div dir="auto">} </div>
<div dir="auto"><br>
</div>
<div dir="auto">This is indeed possible in the current version
of java using sealed types, records and pattern matching.</div>
<div dir="auto">Now it's sad that Optional was introduced before
the features we have now where available and introducing a
second option type would be confusing and terrible for apis.</div>
<div dir="auto"><br>
</div>
<div dir="auto">But I don't think all hope is lost yet. I'm not
too familiar with binary compatibility but from an api
standpoint it would not change the public api of optional if
it was turned from a final class into a sealed interface with
2 inner records representing the 2 states of the Optional
instead of a nullable field. This way the public api of
optional would just be added 2 inner types and otherwise stay
the same. </div>
<div dir="auto"><br>
</div>
<div dir="auto">I would love to hear your feedback on this one.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Great regards </div>
<div dir="auto">RedIODev </div>
</div>
</blockquote>
<br>
</body>
</html>