<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:405841076.113655778.1706288871551.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div data-marker="__QUOTED_TEXT__">
<blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<br>
(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:<br>
<br>
public __inverse List<T> withElement(T element) {
<br>
if (that.size > 0)<br>
_yield that.elements[0];<br>
}<br>
<br>
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.) </blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
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? <br>
<br>
<blockquote type="cite" cite="mid:405841076.113655778.1706288871551.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div data-marker="__QUOTED_TEXT__">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.<br data-mce-bogus="1">
</div>
</div>
</blockquote>
<br>
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? <br>
<br>
<blockquote type="cite" cite="mid:405841076.113655778.1706288871551.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div data-marker="__QUOTED_TEXT__">
<div>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.<br data-mce-bogus="1">
</div>
<div>Is there is another syntactical construct in Java that
behave that way ?<br>
</div>
</div>
</div>
</blockquote>
<br>
Please, let's sync on the model before we turn to syntax. <br>
<br>
<blockquote type="cite" cite="mid:405841076.113655778.1706288871551.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div data-marker="__QUOTED_TEXT__">If the section "Pattern
resolution" is rewritten in terms of bound and unbound
methods, I agree<br>
</div>
</div>
</blockquote>
<br>
OK, so where I think we are is:<br>
<br>
- 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 }<br>
- 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" <br>
- The details of the last one are not fully worked out, that's fine<br>
- The details of exhaustiveness are not fully worked out, that's
fine<br>
<br>
Is that about right?<br>
</body>
</html>