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

Reply via email to