On Tue, Apr 26, 2022 at 2:37 PM Dan Heidinga <heidi...@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.sm...@oracle.com> wrote: > > > > On Apr 26, 2022, at 8:45 AM, Kevin Bourrillion <kev...@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. | kev...@google.com
