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

[Kevin Bourrillion]

On Tue, Apr 26, 2022 at 2:37 PM Dan Heidinga <heidinga at redhat.com> wrote:

The question again is what's the primary reason(s) for exposing a B3
> (.val) vs B2 instance in APIs?  What guidance would we give API
> designers around the use of B3 .val instances?
>

Nice question! I thought about it a little bit and this is my own first
take. I think *most* of the advice would be cross-cutting across param
types, return types, field types, etc.:

If
1. I don't want null to be included as a value
2. I'm definitely not abusing some value as a fake "pseudo-null" sentinel
3. (for a value I'm declaring) I'm willing to take care that it gets
initialized properly
4. I'm properly chastened about racy access

... then I believe the .val is *acceptable*, and I further think that
whenever it's acceptable it's probably *preferred*.

But until I go through this checklist, I'm safer with the reference type.


In the B3 defaults to .ref model, what does the constructor return?
> An L or Q?  Can the user control that?
>
> Remi's "new Complex(r, i)" example left me wondering do users say:
>   Complex.val c = new Complex(1, 2);
> or
>   Complex.val c = new Complex.val(1, 2);
>

The criteria above seem to say that a constructor should always return the
value type (with no need for `new Foo.val`). And good thing, because that's
the way that lets you easily store it into either kind of variable. Yay?




>
> On Tue, Apr 26, 2022 at 1:56 PM Dan Smith <daniel.smith at oracle.com> wrote:
> >
> > On Apr 26, 2022, at 8:45 AM, Kevin Bourrillion <kevinb at google.com>
> wrote:
> >
> > I think I would insist that `.val` be spelled with only one additional
> character... or even that the value type be generated as the snake_case
> form of the name!
> >
> >
> > Okay, this is a meaningful refinement that I find less objectionable.
> >
> > If it's '#Integer128' or 'Integer128!' instead of 'Integer128.val',
> we've trimmed away a chunk of the typing/reading overhead (though it's
> still there, and I think some of the overhead is directly in service of
> what you find attractive—the idea that the value type is something
> unnatural/a departure from the norm).
> >
> > If it's 'integer128' and 'Integer128', well now there is no "default"
> type, and I think we're talking about something categorically different.
> There are some new (surmountable?) problems, but my earlier objections
> don't apply.
> >
>
>

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