robot-simulator: encode position as object instead of string

[HarrisonMc555]

Closes #722.

I decided to use objects. Some people preferred arrays and some people preferred objects, but it seems like in other problems objects were preferred because they were more explicit (see #721). I don't believe we have a policy yet on whether to use arrays or objects for things like this, but I believe that objects would be a better decision. There are some situations in which it doesn't really matter and some people would prefer arrays, but there are some situations where it really would be better to have objects. Since it sometimes is desirable to have objects and only sometimes slightly preferred to have arrays, I think objects are a better default policy.

[stkent]

Nice change! Please also bump the canonical data version as appropriate: https://github.com/exercism/problem-specifications#test-data-versioning :)

[HarrisonMc555]

Thanks, bumped major number.

[Insti]

Good improvement.

[NobbZ]

I do not think, that we really need a major bump.

Nothing has changed. All implementations of the tests can decide to keep the old data structure internally and map the new canonical representation to the most idiomatic representation of the language as it is done with so many other JSON objects already…

So version should in my opinion only get bumped to 1.0.1.

[NobbZ]

Since I can't alter my review… Of course I like the overal change, since it is much more clear how the coordinates have to be read.

Also I do clearly prefer objects over arrays/lists here for the representation of the testdata, since {"x": 1, "y": 2} is so much more obvoius than [1, 2]. To be honest, there were not much of a semantic difference between [1, 2] ans "(1, 2)"…

[Insti]

So version should in my opinion only get bumped to 1.0.1.

I think I agree with this.

(I'm not sure why you cannot 👍 reviews.)

[NobbZ]

It seems as if I had to revoke my request for changes, as per the version numbering documentation, we have to bump MAJOR when we break test generators, and this changes propably will:

MAJOR changes should be expected to break even well-behaved test generators.

I previously always understood the version as a version of the exercise, to understand evolvement of exercises, but it seems as if it were only meant to check for compatibility in testgenerators, nothing more, nothing less.

Misunderstanding versioning guidelines

[Insti]

@NobbZ do you want to make an issue for this discussion? I think it's worth having but we seem to be having this discussion across 3 different PRs. It would be good to have it all in one place we can tag as policy at some point.

[NobbZ]

Yeah, I was going to do so, but first I had to remove false negatives to not block the process of merging.

[petertseng]

I am glad it is getting done.

Squash on merge.

[ErikSchierboom]

Love it! This will allow me to simplify my test generator :)

[HarrisonMc555]

Hey sorry I missed the party. I think I was supposed to squash but didn't get around to it in time. Thanks everyone!