Supporting "build up" of arrays

[ebekker]

Any interest in adding support for "building up of arrays"? What I mean by this is, a normal JSON array could be defined as follows:

{
  "someArray": [
    "foo",
    "bar",
    "baz"
  ]
}

In Hjson, you could allow this alternate format:

{
  someArray += foo
  someArray += bar
  someArray += baz
}

Why? Sometimes when you're working with a configuration that contains an array, the elements of the array have some relationship or reference to some other elements of the overall configuration. In the classic format, you have to keep all the elements together. In the proposed format, you can sprinkle the individual array elements around the config, moving them closer to where they have more contextual meaning.

For example, this is current Hjson:

{
  
  object1: {
    name: Object 1
    type: Type 1
  }

  object2: {
    name: Object 2
    type: Type 2
  }
  object3: {
    name: Object 3
    type: Type 3
  }

  objectReferences: [
    object1
    object2
    object3
  ]
}

And this could be alternative:

{
  object1: {
    name: Object 1
    type: Type 1
  }
  objectReferences += object1

  object2: {
    name: Object 2
    type: Type 2
  }
  objectReferences += object2

  object3: {
    name: Object 3
    type: Type 3
  }
  objectReferences += object3
}

[ebekker]

Note, the proposed syntax above of key += value is merely one possible variation. Other forms that would be either more human-legible, more consistent with current syntax or easier to parse might include:

• key +: value
• key:+ value
• +key: value

The last format might have the least complications -- it's already a supported format for member definitions, but distinguished by the leading plus, so it would only break existing usage where object keys are defined unquoted with a leading plus.

[ghost]

@ebekker
The

+=

comes from Powershell and probably other languages. While it's nice to have such ability as a language feature I don't think that "creating array dynamically" should be done inside data file itself.

[ebekker]

@PSVortex, yes that variation of the syntax was proposed because it is a familiar form to many developers across many languages, but regardless of the notation, I think the feature has merit on its own.

Actually, my personal preference is not even the += format that I initially proposed -- I would actually favor the leading + indicator on the key name myself, which seems to be an easier implementation change as well:

{
  object1: {
    name: Object 1
    type: Type 1
  }
  +objectReferences: object1

  object2: {
    name: Object 2
    type: Type 2
  }
  +objectReferences: object2

  object3: {
    name: Object 3
    type: Type 3
  }
  +objectReferences: object3
}

would be logically equivalent to:

{
    "object1": {
        "name": "Object 1",
        "type": "Type 1"
    },
    "objectReferences": [
        "object1",
        "object2",
        "object3"
    ],
    "object2": {
        "name": "Object 2",
        "type": "Type 2"
    },
    "object3": {
        "name": "Object 3",
        "type": "Type 3"
    }
}

[dqsully]

This is a cool idea, but I think it's a bit awkward for Hjson. While this syntax would make files like your examples easier to write and understand, it's not clear to an untrained eye what +objectReferences: object2 means. Also, +objectReferences is currently a valid unquoted key, so this would be a breaking change.

What about maybe

{
  object1: {
    name: Object 1
    type: Type 1
  }
  objectReferences []: object1

  object2: {
    name: Object 2
    type: Type 2
  }
  objectReferences []: object2

  object3: {
    name: Object 3
    type: Type 3
  }
  objectReferences []: object3
}

I don't know, even that still looks weird to me...

Another consideration with this syntax is the added difficulty to parsing Hjson, especially in strongly-typed implementations, since an array's contents can be scattered around in an object. Parsers would have to cache the scattered array's values and type-check the array only at the end of the enclosing object. It's probably not that big of a deal, just something to consider.

[sffc]

The main drawback for me is that this would add complexity to the Hjson parser. You could have hundreds of these little building-block arrays that would all have to be kept alive in memory until reaching the end of the file.

YAML has some fancy features like these, and mostly people don't actually use them, but parsers still have to support it. Hjson is not YAML.

[ericnewton76]

old thread, but tbh I would not introduce code expressions into the syntax

[ebekker]

It's not really a code expression, per se, the notation is just reminiscent of one in other programming languages but in this case it's strictly a declarative way to break up the collection build up into multiple groups. This can be useful when you want to break up elements of a collection in to related chunks.