[External] : Re: Declared patterns -- translation and reflection

[Brian Goetz]

>     It's not by name.  I don't know where you got this idea. 
>
>
> I think i understand the underlying semantics of the syntax, i'm not 
> 100% confident.

It's always OK to ask questions if you are not 100% sure!   In fact, its 
generally better to do so.

> The problem with the proposed syntax is that you invent a new kind of 
> variable, until now, we had local variables and fields (and array 
> cells but those have no name).

It's valid to have concerns, but (a) please try to understand the entire 
design space before declaring it a "problem" (questions are OK), and (b) 
please wait until we're actually having that discussion.  This is a big, 
complex design space, and there is a clean separation between the user 
model of how it is declared and how it is rendered in the classfile, so 
I'm trying to keep the conversation focused so we can make progerss.  
Please work with me on this.

> Once we have pattern methods, we can have an interface that defines a 
> pattern method and a class that implement it,
> something like

As the "Patterns in the Object Model" document says, yes, patterns make 
sense in interface.  The best example is probably Map.Entry:

     for (Entry(var k, var v) : map.entrySet()) { ... }

These would translate (this conversation is about translation) as 
pattern methods in the interface.  (I haven't thought much about whether 
default implementations make sense.)

> Do we agree that a binding type can be covariant ? (before saying no, 
> think about generics that's the reason we have return type covariance 
> in Java).
> In that case, are we are in trouble with the translation strategy ?

Its a fair question about whether we want this.  When the bindings act 
as a "multiple return bundle", though "covariant return" becomes much 
more complicated; you'd probably need some kind of "meet" restriction 
which says that for any two overrides X and Y that are more specific 
than Z, there is a "meet" W that is more specific than either X and Y.  
Not sure it is worth going there.

It's also a fair question about how it works out in translation, I'll 
think about this.

> Pattern methods (static or not) does not have a real name, so '<' and 
> '>' are here to signal that the name is in the Pattern attribute.
> We do not want people to unmangle the name of pattern methods that why 
> the name is in the attribute, using '<' and '>' signal that idea.

Yes and no.  Remember that the non-dtor patterns in the source file have 
names, and they can be overloaded:

     class X {
         __pattern(bindings) p(args1) { ... }
         __pattern(bindings) p(args2) { ... }
         __pattern(bindings) q(args1) { ... }
         __pattern(bindings) q(args2) { ... }
      }

The mangled name must be unique for each of these, but the first two 
must be derived in part from "p" (so that when the file is recompiled, 
we come up with the same name).  Only dtors are "nameless" and need a 
standin name like <dtor> (or the class name, or any arbitrary spelling 
rule we want to make.)   So while the translated name not be exactly 
name$mangle, the name is important (it can just go into the mangled part 
if we like.)

As with other synthetic members, like bridge methods, we can make it a 
compile-time error to try to override it as a method rather than as a 
pattern.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220330/8b3f3336/attachment.htm>