Level-based Arrays

[3F]

Due to issue #92, We can talk more about various array-type representation in Hjson spec.

My suggestion is to extend the representation of arrays as the Level-based Arrays.

For example, duplicated keys can be considered such as:

key1:
 |
 |--- value1 at key1 line 8
 |
 |--- value2 at key1 line 12
 |
 |--- value3 at key1 line 20

That's much more closer to classic arrays [...].

Level-based Arrays

Hjson spec may wrap duplicated keys as an simple 'Level-based' Arrays.

• Where level means each separated object that can represent its own level. That is, not only the top-level/root object.

The main pros: It can be easily represented in other JSON-based specifications with backward compatibility. While it still can be manageable under specific implementation (because it will be considered as array type that will help to avoid errors as in #92).

draft1

Let's consider the following normal case without duplicates.

Hjson-notation:

{
  key1: value1,
  key2: { x: 1, y: 2 },
  key3: [ 1,2,3 ]
}  

JSON-notation:

{
  "key1": "value1,",
  "key2": {
    "x": 1,
    "y": 2
  },
  "key3": [
    1,
    2,
    3
  ]
}

And the following possible duplicated keys:

{
  key1: value1,
  key1: { x: 1, y: 2 },
  key1: [ 1,2,3 ]
}  

Where 'Level-based Arrays' still can be represented in JSON-notation like:

{
  "key1": [
    "value1,",
    {
      "x": 1,
      "y": 2
    },
    [
      1,
      2,
      3
    ]
  ]
}

Backward representation and its ambiguities

The main task is to consider backward representation for something like this:

{
  key1: value1,
  key1: { x: 1, y: 2 },
  key2: [ 1,2,3 ]
}  

{
  "key1": [
    "value1,",
    {
      "x": 1,
      "y": 2
    }
  ],
  "key2": [
    1,
    2,
    3
  ]
}

Because it can also be understood as:

{
  key1: value1,
  key1: { x: 1, y: 2 },
  key2: 1,
  key2: 2,
  key2: 3
}  

But I think we can also review this part easily due to specific types etc (did not think much for more abstraction, just first thoughts after #92).

Please also note: [?] Backward representation is not main task for this issue.

Other problems

TODO:

---

Cc: @dqsully

[ghost]

@3F FWIW,

key2: [ 1,2,3 ]
cannot be interpreted as

{
  key2: 1,
  key2: 2,
  key2: 3
}

because such 'expand operation' alter the original amount of the keys. The config contains one key2, you need to apply extra logic to expand this key into what you showed.

[3F]

@PSVortex I'm not agree. An 'expand operation' is applicable only for transition state. But this suggestion is just about final nodes/levels.

Means also that backward representation is not main task for this issue. It should be resolved more like separately because of possible ambiguities. Anyway, this is superset that can just independently extend ECMA-404 blind spots.

About complexity is a good question. And I don't think that mentioned extra logic is more complex than currently implemented multiline strings. In O notation it should be exactly like O(n) that more like equality to basic array behavior. That is, we can just accumulate data as we go down to the end of active level.

[3F]

@PSVortex Wait, I just noticed possible misunderstanding with your issue #92:

Notice how easy is to mistype 9 with 0. When such config will be loaded into system, the system will break because of the ThroleLimit will be 0 and noone will know why
...

This suggestion, however, is just additional layer for data representation such as today's all possible strings in Hjson. Your issue was noticed by me just for related things. That's why I do not mean any transitional states above.