<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">Now that the model is
settling, the messages in the suggestion box -- many of them
syntax-driven -- are coming fast and furious now. Here's
another.<br>
<br>
Summary: "Having to type .val will make users angry; can we
please find a way to make it the default at least sometimes." <br>
<br>
The author goes on to suggest a syntax for naming the value
companion explicitly, observing that if the user can pick two
type names instead of deriving the type names from the class
name, then they can give a better name than X.val (perhaps even
"complex") to the value companion (and perhaps a worse name to
the ref, like ComplexRefDontUseMe, further discouraging it.) <br>
<br>
Comment: Yes, we know. We have been trying very, very hard to
not let the syntax tail wag the model dog. Getting to the right
model is the much important thing at this point. (But, I'll
take the flood of syntax-driven comments we've gotten lately as
an indication that the model is mostly there, so that's good.)
Whether or not to allow the user to choose two names (as we
already have for int/Integer) has been hanging in the air for a
long time, but there are more factors there than are immediately
obvious. Let's continue to focus on the model for the time
being; we'll return to syntax in due time. <br>
</font></font>
<div class="moz-forward-container"><br>
<br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Subject:
</th>
<td>Explicit name for value companion type</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Date: </th>
<td>Fri, 1 Jul 2022 14:01:21 +0200</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">From: </th>
<td>Victor Nazarov <a class="moz-txt-link-rfc2396E" href="mailto:asviraspossible@gmail.com"><asviraspossible@gmail.com></a></td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:valhalla-spec-comments@openjdk.org">valhalla-spec-comments@openjdk.org</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<div dir="ltr">
<div>Hello dear experts,</div>
<div><br>
</div>
<div>I've been following the valhalla list for a number of years
already and I'm quite happy with the currently proposed model,
but as others I'd like to raise a concern about making .val a
use-site knob instead of a declaration site.</div>
<div><br>
</div>
<div>I don't think there are a lot of problems, but still I
think the gist of why the use-site usage of .val introduces
distress for people is the following.</div>
<div><br>
</div>
<div>It's easy to miss .val were it should and there is no
immediate indication that something is wrong:</div>
<div><br>
</div>
<div>When performance is not good enough, you need to profile
and look for a place to insert .val. Profiling is costly, many
people have software that can only be realistically profiled
in production. So yes it's easy to fix in a sense, but it's
hard to find where the problem is.</div>
<div><br>
</div>
<div>The alternative that people see is that for some types you
should aggressively go through the code and append .val
wherever this type is available, just to never ever have a
need to profile. I envision that we will get annotations,
static-analysis and even best practices to encourage this. The
worst example that I can invent is something like a naming
convention, so that value classes should always be named with
Ref suffix:</div>
<div><br>
</div>
<div>value class CompexRef {</div>
<div>}</div>
<div><br>
</div>
<div>so that all actual usages will become</div>
<div><br>
</div>
<div>CompexRef.val v = CompexRef.of(1, 5);</div>
<div><br>
</div>
<div>or annotation for static-analysis tool<br>
</div>
<div><br>
</div>
<div><a class="gmail_plusreply" id="plusReplyChip-0" moz-do-not-send="true">@</a><a class="gmail_plusreply" id="gmail-plusReplyChip-0" moz-do-not-send="true">Always</a><a class="gmail_plusreply" id="plusReplyChip-0" moz-do-not-send="true">UseVal</a><br>
</div>
<div>
<div>non-atomic value class CompexRef {</div>
<div>}</div>
<div><br>
</div>
<div>The introduction of conventions and additional tooling is
understandable: it's much cheaper to solve this problem like
this than to profile software on a case by case basis.<br>
</div>
<div>I think this is the main issue, even though the
performance model is adequate and the use-site knob is good
to tweak performance, there are still cases that can be
fixed "once and for all", and people will reach to this
solution no matter what. And I think language has to
accommodate for this and not create a new industry of
static-analysis tools.<br>
</div>
<div><br>
</div>
<div>Another similar case is missing initialization. This is
not so convincing, because we have already become good at
fixing NPE and we already have good static analysis tools
for nullability. But still fixing missing initialization for
some Complex variable based on catched NPE is much, much
more costly then having some kind of static-analysis that
says that Complex should always be initialized to zero. So
here again there is a solution that can "fix NPE" for some
areas without going case by case. And some types, like
Complex, should probably be "just fixed once and for all".<br>
</div>
<div><br>
</div>
<div>So I think this is it, there are no more overlooked
problems, but I think the problem stated above is serious
enough to make people concerned.<br>
</div>
<div><br>
</div>
<div>If I go to a solution, then I don't think I have a
perfect answer, but leaning on "code like a class works like
an int mantra" maybe we can reuse the concept of "permit"
from sealed-interfaces and make value companion to be
explicitly named, like:</div>
<div><br>
</div>
<div>non-atomic value record ComplexRef(int re, int im)
__permits_value_companion Complex {</div>
}</div>
<div><br>
</div>
<div>__value_companion Complex __unboxes ComplexRef {</div>
<div> static Complex of(int re, int im) {</div>
<div> return new ComplexRef(re, im);<br>
</div>
<div> }<br>
</div>
<div>}<br>
</div>
<div><br>
</div>
<div>there should be no explicit state and no constructor in the
Complex value companion, all the state management is performed
in normal class ComplexRef.</div>
<div><br>
</div>
<div>Maybe "__value_companion" should be called "primitive",
because it is not a class, but something that has a "wrapper"
class. We can imagine that Integer and int are defined like
this:</div>
<div><br>
</div>
<div>value class Integer permits-primitive int {</div>
<div>}</div>
<div><br>
</div>
<div>primitive int {</div>
<div>}<br>
</div>
<div><br>
</div>
<div>--</div>
<div>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>Victor Nazarov<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>