[External] Foo / Foo.ref is a backward default; should be Foo.val / Foo

[Kevin Bourrillion]

On Mon, Apr 25, 2022 at 1:53 PM Dan Heidinga <heidinga at redhat.com> wrote:

> Users who have already opted into using a B3 will be annoyed that they
> have to use the bad name to get what they already said they wanted.
> ....
> Users who want the default for B3 to be a reference should
> probably have picked a B2 already.

I strongly disagree with this. Picking B2 is about *taking the choice away*
from your use-sites. By picking B3 they are only saying that the value type
should exist at all. It can't say both that *and* which one is the better
default at the same time.


So we should guide primitive B3 classes to use lower case names?
> "complex" rather than "Complex"?  This started tongue in cheek but
> it's kind of growing on me as a convention.  It matches the existing
> primitives, makes it clear at glance (no need to carry a type
> dictionary in your head), and works fine with the ".ref" escape hatch.
>

It doesn't match the existing primitives if you have to write
`complex.ref`. I think there's a better way to get this :-)

  _value class Complex {} // generates types Complex and Complex.val
  _typealias complex = Complex.val

This would be the way to make it look and work just like int/Integer. I can
at least _imagine_ this being a recommended convention.

(But we have to have a separate conversation on how useful typealiases
could be if done right!)

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com