I’m assuming it has to do with the potential to lose precision when converting from a database decimal into a PHP float so the solution was to cast it into a string instead?
If that’s the reason, I wonder if creating accessors for these in the entity is a better way to handle type conversion instead of having to add (float) when I need explicit type checks.
I’m assuming it has to do with the potential to lose precision when converting from a database decimal into a PHP float so the solution was to cast it into a string instead?
Yes
… instead of having to add (float)
Casting to float defeats the purpose of using decimal type.
Casting to float defeats the purpose of using decimal type.
How so exactly?
I’m aware that floating point values can be non-exact when performing calculations on them, but this is a direct assignment. How is precision lost in that case?
Furthermore, how should one perform calculations on that value when it’s a string? It must be cast into a float for that.
I’m aware that floating point values can be non-exact when performing calculations on them, but this is a direct assignment. How is precision lost in that case?
Just assignment in most cases won’t cause any problem as long as the value in within the range of PHP_FLOAT_MIN and PHP_FLOAT_MAX.
Furthermore, how should one perform calculations on that value when it’s a string? It must be cast into a float for that.
Not sure why I didn’t think of that as I’ve used some in the past. At least the reason for casting into a string makes more sense now given the potential for precision loss in case of range overages.