JsonElement should expose the original value

[bluenote10]

What is your use-case and why do you need this feature?

I'm working with raw schema-less JSON data, i.e., I need to use the plain JsonElement class. The use case involves accessing the underlying value wrapped by JsonElement.

Currently this is awkward and inefficient, because the JsonElement only exposes the underlying value in the form of a String. This requires repeated re-parsing of the string (plus incorporating the isString information) to get e.g. actual boolean/number values etc.

Describe the solution you'd like

I'm completely new to Kotlin, so I lack the skills to draft an ideal solution.

What I would have expected from a user perspective is that the JsonElement is modeled like JSON data is modeled in other languages, i.e., with explicit (sealed) subclasses for JsonString, JsonNumber, JsonBoolean, JsonNull, JsonArray, JsonObject, where all e.g. x.value of the appropriate type.

[bluenote10]

It should be noted that the extension functions defined on JsonPrimitive don't fully solve that issue, because they lose type information. For instance JsonPrimitive("true") allows to extract a boolean although it wasn't constructed from a boolean. My use case also involves maintaining accurate type information.

[sandwwraith]

What I would have expected from a user perspective is that the JsonElement is modeled like JSON data is modeled in other languages, i.e., with explicit (sealed) subclasses for JsonString, JsonNumber, JsonBoolean, JsonNull, JsonArray, JsonObject

Well, there are JsonObject, JsonArray, JsonPrimitive and JsonNull, so you can do

when(element) {
  is JsonObject -> ...
  is JsonArray -> ...
  is JsonNull -> ....
  else -> ...
}

Does it solve your problem?

Regarding type information in JsonPrimitive: see #1298 (comment)

[bluenote10]

No, because JsonPrimitive mixes strings, numbers, booleans, and nulls into a field content: String. The original value is lost, and if you look into how e.g. JsonPrimitive.boolean is implemented you can see the inefficient re-parsing I was referring to.

[sandwwraith]

Then it's a duplicate of #1298, I answered you there