Extra arrayElement after object in array

[e-tobi]

Having this json:

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

I get this sequence of events:

• JsonEventType.beginObject : null
• JsonEventType.propertyName : foo
• JsonEventType.beginArray : null
• JsonEventType.beginObject : null
• JsonEventType.propertyName : bar
• JsonEventType.propertyValue : baz
• JsonEventType.endObject : null
• JsonEventType.arrayElement : null
• JsonEventType.arrayElement : null
• JsonEventType.endArray : null
• JsonEventType.propertyValue : null
• JsonEventType.endObject : null

After the object in the array an extra arrayElement with value null is emitted. This can't be ignored because there actually might be a null in the array.

[aeb-dev]

This is similar to this issue https://github.com/aeb-dev/json_events/issues/6. arrayElement: value marks the end of one of the items of the array. If was storing the object I would have returned arrayElement: {"bar": "baz"} but I can not be sure of the size the object could be huge so I don't store and return it. Instead I just let the parser know that it is the end of current element and we are moving to next

[e-tobi]

Ok. I understand.

If you are ever going to reconsider this, maybe instead of propertyValue / arrayElement, having string/number/literal events feels a little bit closer to the JSON RFC specs. string/number/literal might even be reduced to a single 'literalValue" event with a dynamic value of type String, int, double, bool or null.

• beginArray : no value
• endArray : no value
• beginObject : no value
• endObject : no value
• propertyName: String value
• string: String value
• number: double or int value
• literal: true or false or null

I think this could be slightly easier for the consumer of the events.

[aeb-dev]

Currently, the parser does not have any state so it actually does not know what is it current depth or parent. And I am not sure whether what you introduced can be done without introducing some kind of state. I did not use any state because I believe this is simpler from the perspective of the parser.

With that said I am aware that, I am very opinionated/blind because of the current parser implementation so if you can come up with PR I would be happy to check. I am open to changes but no promises 😄