Towards member patterns

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Friday, January 26, 2024 6:30:33 PM
> Subject: Re: Towards member patterns

>>> (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.

[...] 

> 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 }
yes, for the former, for the latter, the syntax favor the relationship between the pattern and the corresponding method declaration over the consistency of the declaration and the body of the method. So I suppose it depends on how the body is specified, nevertheless it's an interresting idea. 

> - 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"
for me the special mode is more 'instance member qualified with receiver' but yes, 

> - 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?

yes, 

and there is also how to send parameters to the pattern method (and if this is something we should support) that can be added to that list. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240126/e6ca72eb/attachment.htm>