Ciao Maurizio,
admittedly, yours is a fairly convincing argument to wait for the
completion of Valhalla, or at least JEP 401.
Personally, I wouldn't mind having to denote the primitive class as
Decimal128.val in some future (2022? 2023? who knows?) if I could use
Decimal128 tomorrow, but I understand your concerns in defending the
interests of the community at large (which includes myself).
Greetings
Raffaello
On 31/03/2021 15:23, Douglas Surber wrote:
Rather than waiting on Valhala I would prefer that this project be fast tracked
and added to OpenJDK ASAP.
There is a catch here.
While in principle, we can add these as value-based classes, and migrate
to Valhalla later, there is a biggie difference between doing it
before/after.
When it comes to "migrated" primitive classes, there is a choice in how
to interpret the "old" utterances of the class name. Let's say that
class Foo is migrated to be a primitive class; does that mean that all
uses of Foo in existing program will automatically get flattening? Or
will references to Foo be interpreted in a conservative fashion, so as
to allow the same operations as before? One important difference in
semantics is assignment to `null` which is prohibited under flattened
semantics, but allowed under "indirect" (or by reference, if you will)
semantics.
In other words, under the current plan, if Decimal128 is added now and
migrated later, utterances of Decimal128 will behave like they used to
pre-Valhalla, and, to take advantage of flattening you would need to
opt-in with some keyword (e.g. Decimal128.val).
To me this is kind of a strong argument against going with these classes
now (as much as I understand how useful they'd be even w/o Valhalla) -
and preserving the "good" name (Decimal128) for the flattened case seems
worth, IMHO, waiting few more cycles.
Maurizio
