FWD » Core Development » Base Language

In Progress the variable initializer doesn't care much about the declared decimal precision, see below.

def var d1 as decimal extent decimals 1 init [1.55].
message "d1[1] = 1.55" d1[1] = 1.55.
d1[1] = 1.55.
message "d1[1] = 1.6" d1[1] = 1.6.

def var d2 as decimal decimals 1 init 1.55.
message "d2 = 1.55" d2 = 1.55.
d2 = 1.55.
message "d2 = 1.6" d2 = 1.6.

def var d3 as decimal decimals 1 init 1.55.
message "d3 = 1.55" d3 = 1.55.
d3 = d3.
message "d3 = 1.6" d3 = 1.6.

outputs:

d1[1] = 1.55 yes
d1[1] = 1.6 yes
d2 = 1.55 yes
d2 = 1.6 yes
d3 = 1.55 yes
d3 = 1.6 yes

In the converted code, first the initial value is set and then the variable is set with the declared precision.

A possible solution could be to extend the logic of decimal to allow setting the precision for future value updates.

I don't think is worth having both decimal.setPrecision and decimal.setLazyPrecision, because there is no case when setting the precision immediately, correct?

As your API changes are pretty major, please check the MAJIC's srcnew/java code for usage of decimal.setPrecision - and make sure the usage is correct with your findings (i.e. the hand-coded logic is OK with the new "precision is actually set on the next assignment" rule).

About the TODO in setTemporaryPrecision: this is used for shared variables, so you will need to check this, too.

Constantin Asofiei wrote:

I don't think is worth having both decimal.setPrecision and decimal.setLazyPrecision, because there is no case when setting the precision immediately, correct?

As your API changes are pretty major, please check the MAJIC's srcnew/java code for usage of decimal.setPrecision - and make sure the usage is correct with your findings (i.e. the hand-coded logic is OK with the new "precision is actually set on the next assignment" rule).

In the converted code the only use case for setPrecision seems to be the variable definition. If I find the expected usage (precision-on-next-assignment) in the hand-crafted MAJIC code, can I assume there cannot be different use case in the future? I can imagine the behavior can be pretty surprising even when properly documented.

About the TODO in setTemporaryPrecision: this is used for shared variables, so you will need to check this, too.

I will look at the shared variables and create some testcases to cover them.

The only occurrence of setPrecision is in srcnew/java/aero/timco/majic/item/Toolissu.java. There it is used the same way as in the converted code, i.e. with the expected precision-on-next-assignment behavior.

Hynek Cihlar wrote:

In the converted code the only use case for setPrecision seems to be the variable definition. If I find the expected usage (precision-on-next-assignment) in the hand-crafted MAJIC code, can I assume there cannot be different use case in the future? I can imagine the behavior can be pretty surprising even when properly documented.

When writing Java code by hand (which needs to be 4GL-compatible), the developer needs to be careful to use the APIs as they are supposed to. So yes, we can only expect that the API is used in the proper way.

Something else you should cover: the variable definition with an INIT clause, i.e. def var d as dec decimal 2 init 1.22555. As I recall, we emit the initialization value directly at the c'tor and the precision is emitted via a decimal.setPrecision call.

The only occurrence of setPrecision is in srcnew/java/aero/timco/majic/item/Toolissu.java. There it is used the same way as in the converted code, i.e. with the expected precision-on-next-assignment behavior.

OK, this actually is a converted 4GL program which is manually edited to add some logging. So if you don't add a new API and just change the setPrecision to act how 4GL does, then no changes are needed in srcnew/java code.

Constantin Asofiei wrote:

Hynek Cihlar wrote:

In the converted code the only use case for setPrecision seems to be the variable definition. If I find the expected usage (precision-on-next-assignment) in the hand-crafted MAJIC code, can I assume there cannot be different use case in the future? I can imagine the behavior can be pretty surprising even when properly documented.

When writing Java code by hand (which needs to be 4GL-compatible), the developer needs to be careful to use the APIs as they are supposed to. So yes, we can only expect that the API is used in the proper way.

Ok.

Something else you should cover: the variable definition with an INIT clause, i.e. def var d as dec decimal 2 init 1.22555. As I recall, we emit the initialization value directly at the c'tor and the precision is emitted via a decimal.setPrecision call.

Yes. This is actually the case described in the note 1.

The only occurrence of setPrecision is in srcnew/java/aero/timco/majic/item/Toolissu.java. There it is used the same way as in the converted code, i.e. with the expected precision-on-next-assignment behavior.

OK, this actually is a converted 4GL program which is manually edited to add some logging. So if you don't add a new API and just change the setPrecision to act how 4GL does, then no changes are needed in srcnew/java code.

Ok.

Hynek, the changes on 0511a.zip look good. How was the regression testing?

The regression test (after several attempts) passed.

Good! Check in and distribute the changes.

Committed to bzr revision 10532.