Could the idea of null-default inline classes be revisited?
romanowski.mateusz at gmail.com
Thu May 7 21:57:02 UTC 2020
Thanks for the answer.
I have missed the idea of having both through manual transcoding in API
points. However, since accessibility of V.val and V.ref is same, I would
not export V and instead export another type sealed to permit just V.
Nonetheless, thanks for leaving the issue open to become a possible future
extension - I guess there are a few letters remaining to declare new
envelope if a disjoined namespace was needed.
On Wednesday, May 6, 2020, John Rose <john.r.rose at oracle.com> wrote:
> On May 6, 2020, at 12:46 PM, John Rose <john.r.rose at oracle.com> wrote:
> For now, the choice is pretty straightforward: If you
> need null as a value in a variable of type V, use V.ref.
> If you need flatness in the variable, use V.val. Choose
> P.S. If you need both, encapsulate the field as a V.val
> and transcode between V.default and (V.ref)null in
> access methods and constructors. If you need naked
> fields *and* flatness *and* null, you are still out of luck.
> Sadly, record types won’t help with this, thought perhaps
> there’s some limited call for boxing/unboxing relations
> between a record’s internal and external field types;
> that’s another can of worms. Use Java’s class-based
> data abstraction!
More information about the valhalla-dev