robot-simulator: should represent positions as array or object, not string

[petertseng]

Currently, positions are represented as strings like "(11, 5)" in the canonical data for robot-simulator.

For languages where (11, 5) is valid syntax, this seems fine - the test generator will simply be able to interpolate this string wherever it is necessary.

For those languages where it is not valid syntax, it seems like an unusual burden to force test generators for that language to parse the x and y coordinate from the string "(11, 5)".

Consider changing this to an array containing two integers such as [11, 5] or an object with explicit keys such as {"x": 11, "y": 5}.

[rbasso]

I think that using strings is definitely not a good way to represent tuples in JSON. Number should always be represented as numbers.

👍 for an array or an object.

[ErikSchierboom]

Great point! I think having an object would be best as it is the most explicit.

[rbasso]

Encoding tuples as arrays

    {
      "description": "A robot is created with a position and a direction",
      "cases": [
        {
          "description": "Robots are created with a position and direction",
          "property": "create",
          "robot": {
            "position": [0, 0],
            "direction": "north"
          },
          "expected": {
            "position": [0, 0],
            "direction": "north"
          }
    },

Encoding tuples as objects

    {
      "description": "A robot is created with a position and a direction",
      "cases": [
        {
          "description": "Robots are created with a position and direction",
          "property": "create",
          "robot": {
            "position": {
              "x": 0,
              "y": 0
            },
            "direction": "north"
          },
          "expected": {
            "position": {
              "x": 0,
              "y": 0
            },
            "direction": "north"
          }
    },

The Google JSON Style Guide usually recommends avoiding nesting structures
in favor of flatter ones, but that is not a rule:

Data elements should be "flattened" in the JSON representation. Data should
not be arbitrarily grouped for convenience.

In some cases, such as a collection of properties that represents a single
structure, it may make sense to keep the structured hierarchy. These cases
should be carefully considered, and only used if it makes semantic sense.
For example, an address could be represented two ways, but the structured
way probably makes more sense for developers:
(...)

Question: Why the input data is in a robot object and the expected result is not? Isn't the opposite one would expect from a create function?

Anyway, every alternative is better than representing tuples with strings. 😄

[ErikSchierboom]

@rbasso Hmmm, having some sort of official guideline to follow seems like a good idea. It can greatly help creating uniform data. I'm not against using a plain array, if that is what the guidelines recommend.

In fact, now that I see the object vs array example, I like the array better :D