Simplified string version of SET (idea, needs opinions)

[sbcgua]

For manual structure creation (looks quite typical for various API requests), it could be more readable to use a simplified one-line version of set.

    lo_json->set(
      iv_path = '/a/b'
      iv_val  = 'xyz' ).

vs

lo_json->sets( '/a/b:xyz' ).
" or
lo_json->sets( |/a/b:{ iv_param }| ).

• s stands for short or string (would like to keep the method name short)
• type should be probably guessed, e.g.
  • null, true, false, undefined - can be hardcoded
  • 123 - is a number, but "123" is a string (I think edge cases like real string with quotes can be ignored as rare)
  • objects, arrays unsupported ... though theoretically can be parsed ... as it may happen that object has a constant value { "type_id": 12 }
• params - probably ignore, the value of this methods is to cover 90% of "hardcoded" values, there is always normal set for exceptions.
• the fact that this method is slower can be ignored, there is always a normal set to the rescue

Any thoughts ?

[mbtools]

good idea. I would allow any valid JSON value as the xyz part. no guessing or converting types. maybe setval is better.

[sbcgua]

setval sets setv set_v set2

[sbcgua]

I wonder if there should be syntax to directly set root node ? And how should it looks like ?

e.g. if /a/b/c: 123 is a node, then 123 is directly root ? Or maybe :123 ? On the one hand : is more visible and actually means that there is the empty path, which is root. (by the way /:123 can also be an option). On the other hand such a syntax does not have any equivalents in json. While pure 123 is a valid json ...

[mbtools]

I'm usually defining a corresponding structure and do ABAP to JSON or JSON to ABAP. Sometimes getting values directly. But I don't construct JSON via individual set statements. Still set with '/path:value' looks ok to me. To set a string I would do same method with '/path:"value"'

[sbcgua]

Yeah, it's the matter of use-cases then. I find it potentially useful for setting some constants in API structures (which happen) and also in Unit tests which are usually constructed in code with fixed values.

Anyway the code is ready (#142) welcome to review. At least the docs :))

[sbcgua]

Kind of "syntaxic sugar"

[sbcgua]

for the UTs case, abap sadly does not support multiline strings, like e.g. JS

x = `
hello
world
`

[sbcgua]

I guess this can be closed