<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">The latest iteration of the user model for value classes makes it crystal clear that one value class <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code> defines two types.</p>
<p dir="auto">The second type is named <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code> (at present, until that bikeshed is repainted). This is the “value companion” to <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code>, or maybe its “companion value type”.</p>
<p dir="auto">The term “companion” tries to capture the idea that the class doesn’t come alone but travels with some friends, its types. But this pulls in a long and difficult discussion about the exact relation between a class and a type. And then (inevitably) “what’s a class <em>really</em>?” and “what’s a type <em>really</em>?”</p>
<p dir="auto">I think we want to make a distinction between a class and a type. A class is primarily a bunch of source code, later compiled into a classfile. A type is the primary static attribute of a variable in source code, determining its range of values and set of valid operations. As later compiled, the type determines a JVM-level type (usually what we call a field descriptor). The type probably also determines something of the eventual format of the variable in a real machine, although that’s a secret the JVM keeps.</p>
<p dir="auto">In some of our discussions we have called the other companion type of <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code>, which is the (nullable) reference type, by the name <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.ref</code>, as if it were something you could write in source code. Perhaps I should be saying <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.__REF</code> to avoid giving that impression. But perhaps not.</p>
<p dir="auto">(A generic class can engender many, many types. Is this a whole mob of companion types? Perhaps not, but it does call for a clear term for this other relation of classes to types.)</p>
<p dir="auto">(Note also that the “raw type” of a generic class is named by just the class name, sans type arguments: Plain <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">List</code> instead of <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">List<String></code>. And not <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">List.raw</code>, at least not today.)</p>
<p dir="auto">To me it seems useful to treat the two types with a certain amount of symmetry. There is one class, and two companion types, not a class (which is also a type), plus its companion (value) type.</p>
<p dir="auto">If we do this, it makes some further sense to give them symmetrical names, <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.ref</code> and <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code>. We then say that the class name <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code>, used in a context that requires a type, is “just sugar” for the more exact <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.ref</code> (and certainly not <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code>, or you would have used that name).</p>
<p dir="auto">Are there other uses for <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.ref</code>? I can think of just two:</p>
<ul>
<li>
<p dir="auto">For type variables (<em>which are not classes</em>) <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">T.ref</code> (or some other bikeshed color) means “recover the reference companion, even if the generic argument was a value type”.</p>
</li>
<li>
<p dir="auto">For extreme stylized clarity in source code, where someone wants to emphasize that a variable is nullable. (Could this interact with null-inference schemes? Oh, certainly!)</p>
</li>
</ul>
<p dir="auto">The use <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">T.ref</code> lends weight to making the companions symmetric. You can go from <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code> meaning <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.ref</code> to <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code> in <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">List<C.val></code> and then inside <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">List</code> you can go back to <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.ref</code>. It’s a two-way street.</p>
<p dir="auto">There is a limit to treating the two companions symmetrically. Do we really want to allow inner declarations of the form <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">public companion type C.ref;</code>, on the grounds that we do so for the companion <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code>? No, because reference types are “hardwired” by present JVM specifications, and presumably future ones.</p>
<p dir="auto">Maybe we will turn, in the end, to a maximally asymmetric design, with no symmetrical treatment anywhere; no <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.ref</code> in particular. But the cost of that is never being able to refer unambiguously to <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code> as class or as ref-type, except using informal notations or narrative prose.</p>
<p dir="auto">At the moment, though, I like these rules, personally:</p>
<ul>
<li>For a value class name <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code>, <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code> names a type.</li>
<li>For any class or interface name <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code>, <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.ref</code> names a type, meaning the same thing as <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code>.</li>
<li>For any type variable <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">T</code> (in new generics), <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">T.ref</code> names a type.</li>
<li>Maybe: For any type variable <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">T</code> (in specialized generics?), <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">T.val</code> also names a type.</li>
<li>The ref and val suffixes cannot be applied elsewhere. (So no <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.ref.val</code>.)</li>
</ul>
<p dir="auto">Comments?</p>
</div></div></body>
</html>