Allow properties defined as Currency to be automatically initialized

MikeB

When a class property is defined as a Currency data type upon creation of the class initialize the property to 0 or allow the Default for the property to be specified. This would provide consistency with properties of other data types being automatically initialized to default values.

Currently trying to set the default to 0 or 0.00 gives a compile time error of "cannot assign 'Integer/Double' to property type of 'Currency'.

The work around is to add a Constructor to the class and code PropXYZ = New Currency.

bgrommes

MikeB In C#, while one would technically use:

decimal foo = 12.34M; // deciMal ... or Money, if you prefer?
decimal foo = 12.34m; // uncharacteristically for C#, case doesn't matter

... this is still allowed:

decimal foo = 12.34;

... such that in practice, including the M suffix is mostly for clarity of coding intent, or forcing a calculation involving a numeric constant to use decimal rather than double.

IMO it's better if the compiler just accepts integer or decimal constant values so long as there's no runtime type conversion overhead involved. But to avoid ambiguity in situations like this:

Var value As Object = 5.32 + 2.23   # result = 7.5500000000000007
Var value as Object = 5.32m + 2.23m # result = 7.55

... a currency suffix is still needed.

Garry

Great suggestion.

Instead of special-casing property defaults, Currency is now a full value type in the same family as Integer, Double, and DateTime. This is a breaking but intentional language correction, and it's shipping in the next Studio release: https://feedback.objo.dev/feature/1083

Currency now defaults to zero everywhere. No constructor needed.
Any Currency that hasn't been explicitly assigned is automatically Currency.Zero. The old workaround (PropXYZ = New Currency in a constructor) is no longer required:

   Class Account                                                                                                                                                                    
       Property Balance As Currency   # zero by default                                                                                                                             
   End Class

You can now specify defaults directly, including literals.
Wherever the destination is statically Currency, an exact numeric literal can be assigned.

   Property Balance As Currency = 12.34                                                                                                                                             
   Property Fee As Currency = -1.25                                                                                                                                                 
   Var total As Currency = 5                                                                                                                                                        
   Var arr As Array(Of Currency) = [1.25, 2, -0.5]

Currency can never be Nothing.
Assigning or comparing Currency with Nothing is now a compile-time error. Values have raw-value equality, hashing, and copy semantics; zero is falsy, non-zero is truthy.
Everything else is preserved.
New Currency(), New Currency(number), Parse(), etc as well as all the arithmetic/comparison operators, and all the formatting overloads behave exactly as before. Currency also remains distinct from Number.

bgrommes

Garry My admittedly obscure example of where suffixing would be useful could then would just become:

Var foo As Object = Currency(5.32) + Currency(2.23) # or would it have to be new Currency(5.32), etc?

... and since I can't think of a time I've actually had to do this for some reason, might as well keep the syntax simple.

I have had a tendency to (occasionally) use suffixing of numeric constants in C# partly to make the intent explicit and partly because in the absence of suffixing, the compiler distinguishes constants that are floats and doubles from integers by them having an integer portion whether it needs it or not, but would have no certain way of knowing in all situations whether you intend a double or a decimal value when you have a constant like 5.32. Presumably the same is true in Objo: if you're assigning to a double, then all constants in an expression would be doubles; same for currency, etc; it's only when the assignment target is vague that it would make Assumptions -- presumably in favor of double.

Question, just for thoroughness: what's the precedence in these scenarios for double vs currency? Currency's advantage is its ability to avoid many classes of rounding errors; its disadvantage is less decimal places of precision, and, presumably, it's a bit slower than double, or that's the case between decimal and double in C# -- there, it's massively slower, as in 15-30x slower, which is probably down to the 128 bit C# implementation and the ability to scale to up to 31 decimal places (which also makes it more demanding of memory). However, in practice, the benefits for line of business apps far outweighs this, and typical design patterns don't involve, e.g., matrix math with decimal.

Currency, while not an exact analog to decimal, seems plenty adequate in terms of what I have actually ever used the decimal type for in C#, and I would expect it to be much more competitive with double as well, if I cared to benchmark it. It's also nicely compatible with Money types in some DBs.

Garry

Good questions. There isn’t a precedence rule where either Double or Currency automatically wins; the operand types determine the operation.

Your example works as written:

Var foo As Object = Currency(5.32) + Currency(2.23)

Here, Currency(...) acts as an explicit cast. Because both values are exact Currency literals, the addition is Currency arithmetic and foo contains a Currency value of exactly 7.55.

New Currency(...) is also available, but it serves a slightly different purpose: it converts an Integer or Double and rounds to four fractional digits when necessary. For example, when converting a calculated Double, use either:

Var amount As Currency = New Currency(someDoubleExpression)

or:

Var amount As Currency = Currency.FromDouble(someDoubleExpression)

A bare real literal such as 5.32 is otherwise a Double. Contextual conversion applies when an exact literal is directly required to be Currency:

Var amount As Currency = 5.32  # Currency

It does not propagate backwards through an entire expression:

Var amount As Currency = 5.32 + 2.23  # Double arithmetic; compile error

Similarly, addition and subtraction require Currency on both sides. Multiplication and division may use an Integer or Double scalar:

Var price As Currency = 19.95
Var total As Currency = price * 3

Currency / Currency returns a Double, since the result is a ratio rather than an amount.

On performance, Currency is not implemented like C# decimal. It is an inline fixed-point value backed by a scaled 64-bit integer, with four fractional digits and no heap allocation. Addition and subtraction operate directly on those scaled integers. Multiplication and division perform decimal rescaling and rounding internally, so I wouldn’t claim they are as fast as Double without benchmarks, but the design is intentionally well suited to normal business and financial calculations.

It also maps naturally to fixed-scale database columns, and its ScaledValue property is available when exact raw persistence is useful.

So I agree with your conclusion: a Currency suffix would add language complexity for a fairly obscure case that can already be expressed clearly with Currency(...). I’m inclined to keep the syntax simple.

bgrommes

Garry Thanks, Garry. That makes perfect sense. I actually like Currency better than decimal, at least for any use case I have personally encountered.

As far as currency conversions, I have seen people design a Money or Currency type that stores the currency represented or has some sort of support for currency conversions, but in practice I feel the exact requirements for that vary so much that it is better for individual architects to work that out. For example I've done a lot of work for several different commercial credit bureaus. In that context we just convert everything to USD for storage and convert to other requested currencies on the fly in reports, based on a single conversion factor per month, representing the markets as of the last business day of the month the data covers. That's imperfect but plenty close enough for credit decisioning purposes (except maybe in edge cases that if they ever obtained, we would be looking at some sort of apocalypse, lol). Other applications would need to integrate a conversion service to provide realtime converted values based on the exact date, etc.

So IMO your currency type is solid and does the job it needs to do.