The good and the bad static pattern ?

[Tagir Valeev]

I think it should be essential to be able to declare a pattern outside of
the type it matches. We cannot declare all possible string patterns inside
the java.lang.String. People would like to declare their own string
patterns.

With best regards,
Tagir Valeev

On Mon, Jan 18, 2021 at 3:03 PM Remi Forax <forax at univ-mlv.fr> wrote:

> In the last document sent by Brian, there is a notion of static Pattern.
>
> Here is an example of static patterns
>   switch(o) {
>     case String.matcher("(a*)(b*)", matcher -> ...
>     case Integer.parseInt(var value) -> ...
>   }
>
> The first pattern, check if o is an instance of a String that match the
> regex "(a)(b)" and provides the Matcher to retrieve the matching groups.
> The second pattern, check if o is an instance of a String and can be
> parsed as an integer and bind that integer to value.
>
> The first pattern correspond to an instance method inside
> java.lang.String, while the second pattern correspond to a static method
> inside java.lang.Integer.
>
> One problem is that while it's obvious that the first pattern starts by
> checking if o is an instanceof String,
> it's far less clear from a user POV that the second pattern does exactly
> the same thing and does not check if o is an instance of Integer.
>
> So should we support the form of the second pattern, a static Pattern
> linked to a static method ?
> Or should we restrict ourselves to static patterns that are expressed as
> instance method ?
>
> regards,
> Rémi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210118/c547271b/attachment.htm>