<div dir="ltr"><div>From what I have seen in some examples, I believe you will be able to do:</div><div><span style="font-family:comic sans ms,sans-serif"><br></span></div><div><span style="font-family:comic sans ms,sans-serif">switch(opt) {</span></div><div><span style="font-family:comic sans ms,sans-serif">  case Optional.of(var value) -> // use non-null value here</span></div><div><span style="font-family:comic sans ms,sans-serif">  case Optional.empty() -> // handle absent case<br></span></div><div><span style="font-family:comic sans ms,sans-serif">}</span></div><div><br></div><div>This will likely be possible with the introduction of deconstruction patterns: <a href="https://gist.github.com/babanin/9ddf60279a9cbe50260ddb11d1aa2e80#recovering-static-factory-arguments">https://gist.github.com/babanin/9ddf60279a9cbe50260ddb11d1aa2e80#recovering-static-factory-arguments</a></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards<br></div><div>Swaranga</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 26, 2024 at 12:35 AM Red IO <<a href="mailto:redio.development@gmail.com">redio.development@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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-wrap">        </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-wrap">    </span>case Some(foo) -> {} </div><div dir="auto"><span style="white-space:pre-wrap">   </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></div>