Is V? what we need ?
john.r.rose at oracle.com
Wed May 1 22:55:19 UTC 2019
On May 1, 2019, at 7:50 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> I fully agree, it's like getting ride of Integer, it's a fantasy, but not having a lot of API taking a N? as parameter type make that fantasy actually possible for the libraries you care.
> We can’t get rid of Integer, but maybe we can make it 10x less important. That would be winning.
I agree with this. It is an argument to "cripple" V? (aka V*)
as Remi is suggesting.
A counter argument is that this makes code gratuitously
hard to use; auto-unboxing of Integer is a decision to
partially un-cripple Integer.
Fully crippled case: The type V? has no operations except a
null constant (V?.default), an explicit conversion from V ((V?)x),
and an explicit conversion back ((V)x).
Fully functional case: The type V? is a super of V, interpreted
as V with null adjoined (if not already present), *and* all operations
of V are lifted to V? with a NPE thrown for null.
My guess is we will end up somewhere between; there
are many points in between, including today's policy about
I agree it doesn't help much to talk about "boxes" as a generic
design tactic. There are too many design degrees of freedom.
Maybe there are "coffers" in our future, but the real question
is what operations are available on V? (aka V*).
I agree with you, Brian, that the best user model outcome
will make boxes disappear as separate APIs. This means
that either V? (aka V*) has a trivial API, or else its API
differs trivially from that of V, so that the "?" denotes
more of a mode of use, than a full-blown API. I would
prefer the latter.
More information about the valhalla-spec-experts