> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>, "amber-spec-experts"
> <amber-spec-experts@openjdk.java.net>
> Envoyé: Mardi 19 Janvier 2021 18:05:11
> Objet: Re: The good and the bad static pattern ?
> To put this in context, let's look at what other curly-brace language have
> done.
> Scala's pattern matching leans primarily (IMO, way too much) on static
> patterns;
> most patterns in Scala are static methods called "unapply" that takes the
> target as an ordinary parameter and encoding their bindings with some (ad-hoc)
> combination of optionals, booleans, and tuples. Scala simulates deconstruction
> patterns with this, as well as the use cases we've described for static
> patterns. (Scala also has "pattern objects", whose unapply methods are
> instance
> methods, but this isn't exactly like the instance patterns we're proposing
> here.)
> C#'s pattern matching has only deconstruction patterns; you define a
> `Deconstruct` method, which is like our deconstruction patterns.
> What's new here is that we are trying to integrate these concepts into the
> object model in an organized and intrinsic way, rather than trimming around
> the
> edges. Declared patterns are code that tells us how to take a target and
> conditionally extract the bits we want. The novel idea here is that this
> really
> should have been part of the object model all along; we have many language
> features for aggregation, but we leave destructuring as an "exercise for the
> reader."
> Remi, is your discomfort about static patterns basically "Well, Scala gets
> away
> with having only one kind, that subsumes deconstruction and static, isn't that
> good enough?"
Not exactly, it's more than if a static pattern that reference a static method,
the type of the first parameter is not visible for a user.
Let my try to explain in a simple way.
when we write
Object o = ...
switch(o) {
case Bar$$foo(3, var value) -> ...
}
I've replaced the dot '.' by $$ because the semantics is not exactly the
semantics of the static method call.
What the operator $$ does is invoking the pattern method Bar.foo with 'o' as
first argument.
So there is an implicit argument and there is a dynamic test that 'o' is an
instanceof of the type of the first parameter.
The problem is that the type of the first parameter is not visible anywhere in
the syntax, that the part that trouble me.
Here, I've no idea if foo takes a String, an Integer or whatever as first
parameter, so i've no idea on which class the instanceof is done.
Rémi
PS: i don't know if you know the following paper that uses polymorphic
extractors [ https://dl.acm.org/doi/abs/10.1145/3357765.3359522 |
https://dl.acm.org/doi/abs/10.1145/3357765.3359522 ]
> On 1/18/2021 3:03 AM, Remi Forax 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
