Hi Noah,
I think you can code it the way you want it. But I'm not sure if this is desirable. You'll end up with some problems in the end that I'm not sure if it's worth it. Consider the following JSON strings:
Json1: {name: "Roberto", age: 32}
Json2: {name: "Roberto", age: 32.5}
Json3: {name: "Roberto"}
Json4: {age: 32, name: "Roberto"}
Because JavaScript is dynamically typed, it allows JSONs to be flexibly structured. Dana, on the other hand, is statically typed, meaning that if "age" is defined as int you won't be able to assign a 32.5 value to it (not without casting -- even if the casting is implicit).
So, the way we coded JSONEncoder, we made sure that it can convert all 4 JSON string examples into the same Dana data type. That's important because it ensures that whoever is using JSONEncoder knows the type "jsonToData()" is converting the JSON string into, and that makes JSONEncoder safe to use for whatever JSON string you pass as a parameter.
If you implement jsonToData() the way you want it, for each of the 4 JSON string examples you'll end up with a completely different Dana data type. For all the possibilities you have to format your JSON string, you'll end up with a different Dana data type. This makes "jsonToData()" somewhat unpredictable and difficult to use -- unless you craft your JSON strings very carefully (considering type orders, type names, and not omitting values even if they are null). That means you won't be able to receive JSON strings created from a different system with confidence it'll work all the time. Not sure if this is worth it.
But if you still wanna try, have a look at the "reflection" section on the Dana guide: https://www.projectdana.com/dana/guide/reflection
Roberto