<div dir="ltr">Sorry to send this as follow up, but I figured there are some points that have been left unaddressed.<div><br></div><div>Firstly, I am aware that patterns are dual of factories. There is no duality in what I am asking for (at least it can be used without duality), although it can still be used as dual (as token patterns could be dual to corresponding token type factories, in my example).</div><div><br></div><div>Secondly, if we are talking about extending standard library APIs, as for every other extension (collectors, for example), there would be some lack of discoverability. Not that it makes it a bad way to extend existing code, just think it is worth pointing out.</div><div><br></div><div>Lastly, the example I have provided, which is obvious for me now, does not make much sense. THe thing I want to propose now, if applied to example above, should look something like this^<br><br>switch (strToken) over TokenKinds {</div><div>case matchesHeavy(HeavyToken t) -> ...</div><div>case matchesErroneouse(ErroneousToken t) -> ...</div><div>...</div><div>}<br><br>This example makes much more sense then what I have shown above after researching how patterns are intended to work. Not even sure what I was trying to express above to be honest :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 3, 2024 at 5:00 PM Olexandr Rotan <<a href="mailto:rotanolexandr842@gmail.com">rotanolexandr842@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="ltr">I have been recently looking through devox speeches, and one of the points you have made reminded me about this conversation. The thing you said is something like "if we had pattern matching back in java 8, we could have implemented the following for the CompletableFuture" and showed an example of switching over possible states (like interrupted, completed etc). And what has crossed my mind is that this is almost what I have tried to express. <div><br></div><div>If I understand correctly, member patterns are a way to say "I declare a, possibly exhaustive, set of states that class that patterns are members of could take". This is a good thing obviously, but this only works if one has access to source code of the class one wants to declare states of.</div><div><br></div><div>What am I asking for / suggesting, is to also add the possibility to declare such set of states for external classes. More formally, I want to be able to state something like "I declare a set of states X that type Y could take in the subject area  Z, that could be exhaustive if asserted". Using an example with tokes, I could reformulate this as follows: "I declare a set of states TokenKinds that type String could take in the subject area "Tokens", that is exhaustive by assertion". Subject area is not something present in language semantics, more of a topic that unites this set of states. Applying to CompletableFuture, this feature could introduce something like:<br><br>switch (future) over AsyncStates {</div><div>case Completed(var result) -> ...<br>case Interrupted -> ...<br>case Failed(var ex) -> ...<br></div><div>}<br><br>Note that "over AsyncStates" asserts that only patterns from set of states AsyncStates could be present</div><div><br></div><div>This could help adapt existing APIs to new java paradigms and features without having to modify them directly, which is in many cases at least unpleasant. Also, this opens a world of possibilities for users, by enabling them to use custom patterns on types they cant access source code of. Not limited to the Java standard library, It could be also useful in frameworks, with tasks like checking if principal is anonymous/logged in/unauthorized, and a huge pile of other ways that people could apply this feature.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2024 at 6:27 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.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"><br>
<br>
On 4/29/2024 10:02 AM, Olexandr Rotan wrote:<br>
> I think I did a really poor job expressing my thoughts in the first <br>
> message. I will try to be more clear now, along with some situations I <br>
> have encountered myself.<br>
><br>
> Assume we have a stateless math expressions parser. For simplicity, <br>
> let's assume that we split expressions into several types: <br>
> "computation-heavy", "computation-lightweight", "erroneous" (permits <br>
> null as input) and "computation-remote" (delegate parsing to another <br>
> service via some communication protocol), and types can be assigned <br>
> heuristically (speculatively). For some tasks, we need to perform some <br>
> pre- and postprocessing around core parsing logic, like result <br>
> caching, wrapping parsing into virtual thread and registering it in <br>
> phaser etc., for others - log warning or error, or fail parsing with <br>
> exception.<br>
<br>
If you are envisioning side-effects, then I think you are already <br>
abusing patterns.  Patterns either match, or they don't, and if they do, <br>
they may produce bindings to describe witnesses to the match. Exceptions <br>
are not available to you as a normal means of "something went wrong"; in <br>
writing patterns (you should think of throwing an exception from a <br>
pattern declaration as being only a few percent less drastic than <br>
calling System.exit()).<br>
<br>
Patterns, as explained in the various writeups, are the dual <br>
(deconstruction) of certain methods (aggregations.)   I don't see the <br>
duality here.  (If I had to guess, you're trying to bootstrap your way <br>
to parser combinators with patterns, but that's a different feature.)  <br>
So I'm still not sure that you're using patterns right, so I still want <br>
to focus on that before we start inventing new features.<br>
<br>
Case patterns are a form of ad-hoc exhaustiveness, to be used only when <br>
other sources of exhaustiveness (e.g., enums, sealed types, ADTs) fail.  <br>
It isn't clear to me yet that these other sources have failed.<br>
<br>
<br>
</blockquote></div>
</blockquote></div>