Preserve trailing dot+zero when converting floats to string

Issue #95 new
Francois Normandin created an issue

This is not a bug as per JSON specification, but rather a convenience for reverse parsing and type assumption.

“Variant to JSON Text.vi” removes the trailing zeroes and the dot when the number representation does not have decimal points. This is usually done for compactness and reducing the number of bytes in the payload. However, it prevents reverse parsing inspection from getting a hint at the expected datatype. This is somewhat related to issue #39.

The proposal is to not remove the dot when in presence of a float.

Fix would imply these changes:

  1. DBL to String.vi, case(-2147483648) : replace “0” with “0.0”
  2. SGL to String.vi, case (-2147483648): replace “0” with “0.0”
  3. Remove trailing zeros.vi, case “0x2E”: remove “decrement” node.

Comments (7)

  1. James Powell repo owner

    I think by the spec a trailing dot isn't allowed, but .0 would be allowed.

    Would a Conditional Disable that allows you to turn this on be acceptable to you?

  2. Francois Normandin reporter

    I read the spec again and I agree that a trailing dot is not allowed.

    A fraction part is a decimal point followed by one or more digits.

    As for a conditional disable flag, I don’t think this is a proper way to handle it as the same code would execute differently when called from within our outside a project. It would probably trigger failures of automated pre-build unit tests or force that those tests are run within configured projects.

    I’d rather not have different behaviors based on a flag that is hard to document, or that another developer will not think about.

    If a conditional flag is the solution, could this be one of those rare cases where a global variable is actually a better way? I’d prefer an outright change to always return .0, but adding a node in the advanced palette to toggle this flag to True would at least allow the flag to be settable as part of a class constructor. It would be more transparent for documenting the feature from the user’s perspective.

    Thoughts?

  3. James Powell repo owner

    You’re more likely to convince me to do .0 as standard, rather than use a Global Variable, as on consideration I did think up a reason that it seems useful to me: in Config Files. Config files often have optional parameters that are whole numbers by default, but can be set as fractional values, and seeing “0.0” or “1.0” will signal to the User that the number can be fractional.

    Also, the extra size of the JSON is probably not important, as when one writes a lot of float values (such as saved data) the large proportion of them are going to have 6-13 fractional digits anyway.

  4. Log in to comment