On Mon, Apr 25, 2022 at 1:53 PM Dan Heidinga <heidi...@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. | kev...@google.com
