On Thursday, 30 October 2025 at 12:16:36 UTC, Dennis wrote:
On Thursday, 23 October 2025 at 01:50:55 UTC, Hipreme wrote:
Hope you guys enjoy it :)
https://code.dlang.org/packages/hipjson
Very nice! I wonder why you chose to follow std.json's
interface with dynamic objects, rather than an introspection
based `parseJson(T)(ref T obj, string jsonData)` which fills a
struct/class T with values from the json text, ignoring unknown
keys.
Can this become a std.json replacement in Phobos v3 (or even
v2)?
Redub uses a cache system in which the hash of an object becomes
a key. This does not translate well to structs as they are
"random" keys.
Beyond that, dub also does use platform filters such as
"dflags-ldc". In which one can make arbitrary combinations, which
is also a problem. That being said, dynamic objects are way more
flexible.
Another use-case where it doesn't fit very well is for
representing file system. Since the filesystem contents are
dynamic, that is another reason. This is used for checking valid
accessible files in my wasm API.
There is another case in which the dynamic type API is kinda
important, which is mostly when you do union types, so one would
still need a good representation of it:
```json
"directionals": {
"move": {
"x": [
{"keyboard": "a", "gamepad": "dPadLeft", "value":
-1},
{"keyboard": "d", "gamepad": "dPadRight","value":
1},
{"analog": "left", "axis": "x"}
],
"y": [
{"keyboard": "w", "gamepad": "dPadUp", "value":
-1},
{"keyboard": "s", "gamepad": "dPadDown", "value":
1},
{"analog": "left", "axis": "y"}
]
}
}
```
For my input API, it also receives arbitrary actions which can be
referenced to the player, and in an array of an union type of
either a value or an axis. Really complicates the algorithm. And
also I wanted a std.json API since I was already using it in my
projects, so it makes it much easier to migrate.
As a final input, I also don't really like using templated code.
It is also very easy to create a deserialization function based
on a struct, so, if one day I decide to add that API, it will be
a 0 effort migration.
