<div dir="ltr"><div dir="ltr">On Thu, Jul 21, 2022 at 4:01 PM John Rose <<a href="mailto:john.r.rose@oracle.com">john.r.rose@oracle.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">(Oh, and please please do not have <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">Object::getClass</code> return different values for variables of type <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C.ref</code> and <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C.val</code>; I think I see that suggested from time to time!)</p></div></div></div></blockquote><div><br></div><div>(plug: imo there are only 3 Object methods that have any business even *compiling* when called on val receivers.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Your appeal to <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">this</code> has a special benefit when <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C</code> is generic:  It captures the most general type possible, of the form <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C<T></code>.</p>
<p dir="auto">(Except for conditional methods if we ever do those; then <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">this</code> might have a conditional bound on a parameter.  The root problem is that <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">T</code> will probably mean something subtly different in a conditional method, so <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C<T></code> doesn’t mean just one type everywhere in <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C</code>.)</p></div></div></div></blockquote><div><br></div><div>Agreed. I'd guess it would resemble that method introducing its own type parameters, bounded by the class's, and hiding them.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
</div><div style="white-space:normal"><blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)"><p dir="auto">(Sorry for digression: you could also say one class engenders many array
<br>
types, though. I think it helps to fully distinguish predefined,
<br>
user-defined, and composed types. Setting aside value classes temporarily:
<br>
each class directly defines just one type, which is the type of `this`
<br>
inside the class itself (the "implicit type", or the "this-type"). That's
<br>
the all-important type whose member signatures are seen in the class and
<br>
whose supertypes are seen in the class signature. Other types can be
<br>
composed out of the defined types: array types, type variables,
<br>
intersection types I guess, and relevant to us here, all *other*
<br>
parameterized types beyond the implicit type. That is, imho it's most
<br>
fruitful to understand those parameterized types as deriving from the
<br>
implicit type/"this-type", with member signatures and supertypes being
<br>
calculated from that implicit type via substitution, rather than to see
<br>
them all as popping directly off of the generic class.)</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Yup, when is a related type a true companion, and when is it just a projection?  We get to define this, and then we have to live with it.</p>
<p dir="auto">It’s an interesting outcome (of your <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">this</code> position) that <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C<T></code>, out of all the generic instances of <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C</code>, is elevated to principal position, and all other <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C<U></code> are mere projections of <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C</code>.</p></div></div></div></blockquote><div><br></div><div>Yes, in my mind, it is already elevated: it's the type whose supertypes and method signatures are actually being specified directly by the class. That's such an essential role it is playing.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">(Surely you already considered and rejected the following alternative choice of narrative in your document, which I will state here FTR:  The principal type of <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C</code>, when <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C</code> is generic, is its <em>raw type</em>.  That is much less useful for speaking about the type of expressions derived from <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">this</code>, but it aligns much more closely with the other “questions” I alluded to above:  “What is the type denoted by merely the class name <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C</code>?”  And “What is the mirror returned from <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">Object::getClass</code> when invoked on an instance of class <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C</code>?”)</p></div></div></div></blockquote><div><br></div><div>Gross! :-)</div><div>I think pretending raw types don't exist (as much as possible) leads to more virtue than vice.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
</div><div style="white-space:normal"><blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)"><p dir="auto">I see some sense in your argument, but I still can't think of a reason I'd
<br>
want to see `ClassName.ref` in source code. It seems like that can't add
<br>
any information.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">I mean it can adds a certain connotation (“stylized clarity” as I said) to the code.  Have you ever written a fully-qualified name where it wasn’t necessary?  (I have, when I wanted to emphasize where the symbol came from:  Such emphasis is connotation not denotation.)  Have you ever written <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">public</code> on an interface member where you didn’t need to?  Again, I’d call that choice a matter of stylized clarity.</p></div></div></div></blockquote><div><br></div><div>If I do those things, someone else comes along and cleans them up. :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Depending on how type inference works, <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">ClassName.ref</code> vs <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">ClassName</code> might affect TI, as <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">List<ClassName.ref></code> vs. <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">List<ClassName></code>.  This is, I think, the case with certain drafts of Valhalla-related generics.</p>
<p dir="auto">I made a sly reference to null-inference.  As with type inference, I could imagine designs of NI where <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">ClassName.ref</code> vs <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">ClassName</code> produces a different inference about null.  Suppose there’s some way of saying, for <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">ju.Optional</code>, that only a dope would make null values of that reference type.  Then <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">Optional.ref</code> could possibly be a way of saying, “I’m that dope, bear with me.”</p></div></div></div></blockquote><div><br></div><div>fwiw (which isn't much), this all makes me feel uneasy.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
</div><div style="white-space:normal"><blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)"><blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(153,153,153);color:rgb(153,153,153)"><p dir="auto">- Maybe: For any type variable T (in specialized generics?), T.val
<br>
   also names a type.</p>
</blockquote><p dir="auto">If I ever see `T.val` (except maybe the case of `T.val[]`??) I will assume
<br>
some kind of templating must be going on, since we'll all have learned
<br>
early on that there is no polymorphic interaction with values. Is that your
<br>
expectation too?</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">I’m imagining, at least, some sort of additional “leakage” of ref/val distinctions into the scope of <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">T</code>.  We have such leakage already otherwise <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">T.ref</code> wouldn’t be useful; it happens when a generic API is bound to type arguments and <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">T</code> looks like <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C.val</code>.  I think the consensus is that the use cases don’t support doing the reverse, of allowing <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">T.val</code> to mean <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C.val</code> when <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">T</code> is <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C.ref</code>, but it’s logically possible isn’t it?  And if so a use case may show up.</p></div></div></div></blockquote><div><br></div><div>Again it just puzzles me, since I expect that part of the whole deal with value types vs. reference types is that you always need to know exactly what type you're working with. So how could I interact generically with `T.val`? Unless templating. The array case seems sensible to me though, because I can figure that the array's header must be keeping track of the precise value type.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Independently, something like what Remi discusses, of flattening to val-type inside a generic bound to a ref-type, could be a use of <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">T.val</code>. I think you surmised that: <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">new T.val[n]</code> could be an optimistic dynamic buffer, if the actual type <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C.val[]</code> were somehow available at that point.  That would require even more “leakage” of information about type arguments beyond the API of a generic and into its method bodies and maybe even field types.  Eventually you would use such information to “fill in templates”, including flattening fields to <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C.val</code>.</p>

</div></div></div>


</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div></div>