Towards member patterns

[Brian Goetz]

>
>     (It could also be a default pattern; works the same as default
>     methods.)  The implementation in emptyList always fails.  The
>     implementation in ArrayList might look like:
>
>         public __inverse List<T> withElement(T element) {
>             if (that.size > 0)
>                 _yield that.elements[0];
>         }
>
>     Now, implementing this guy gets tricky, since we have two context
>     variables which are both of the same type, ArrayList<T>.  (Maybe
>     we have to explicitly use a covariant "override" here; TBD.) 
>
>
> I do not think allowing covariant override is sound. Because if the 
> method is unbound, yes, 'this' and 'that' are the same object at 
> runtime, but if 'this' is bound, these are two differents objects so 
> no covariant override should be allowed.

Maybe, but let's checkpoint first, because we're in the weeds, and 
before we finish designing this corner of the story, let's first sync on 
the big picture.

You were concerned that there was no way to have, say, a List 
implementation provide its own implementation of a pattern.  I've shown 
that the design allows for that, that the machinery is in place, and 
that there still a few details to work out.  Do we agree that your "all 
the patterns are static" was a misunderstanding?

> I think that using '::' instead of '.' is a great simplification, 
> because it let the user to specify how the linkage is done, unbound or 
> bound.

Lets leave syntax aside, but are you saying that both bound vs unbound 
seem desirable, and there should be a way to explicitly specify which it 
is?  Or are you making a different point?

> Also I do not think it's a good idea to have a syntax which is context 
> dependend, i.e Type.method() and Type.method() having different 
> meaning/linkage semantics inside or outside a Pattern.
> Is there is another syntactical construct in Java that behave that way ?

Please, let's sync on the model before we turn to syntax.

> If the section "Pattern resolution" is rewritten in terms of bound and 
> unbound methods, I agree

OK, so where I think we are is:

  - We basically agree that each of { deconstructor, static pattern, 
instance pattern } are useful and have valid use cases, and to the 
extent possible, we should be guided by the duality with { constructor, 
static method, instance method }
  - We basically agree that at the use site, we have all the 
qualification modes we have with methods { constructor qualified with 
package, static member qualified with type, instance member qualified 
with receiver } , and possibly, an additional mode of "instance 
qualified by type"
  - The details of the last one are not fully worked out, that's fine
  - The details of exhaustiveness are not fully worked out, that's fine

Is that about right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240126/7f58bc63/attachment.htm>