4 ms·

You can't get much more 'opinion-less' than this library though. Iterate over keys and array items, identify the value type and return string-slices.

IshKebab 1y ago
It also feels like only half the job to me. Reminds me of SAX "parsers" that were barely more than lexers.
- flohofwoe 1y ago
  I mean, what else is there to do when iterating over a JSON file? Delegating number parsing and UNICODE handling to the user can be considered a feature (since I can decide on my own how expensive/robust I want this to be).
  - skydhash 1y ago
    That is what I like Common Lisp libraries. They are mostly about the algorithms, leaving data structures up to the user. So you make sure you got those rights before calling the function.
  - IshKebab 1y ago
    Extracting the data into objects. Libraries like Serde and Pydantic do this for you. Hell the original eval() JSON loading method did that too.
    - meindnoch 1y ago
      Then you lose the ability to do streaming.
      - IshKebab 1y ago
        True, but usually you only need that if your data is so large it can't fit in memory and in that case you shouldn't be using JSON anyway. (I was in this situation once where our JSON files grew to gigabytes and we switched to SQLite which worked extremely well.)
        meindnoch 1y ago
        Actually, you'll hit the limits of DOM-style JSON parsers as soon as your data is larger than about half the available memory, since you'd most likely want to build your own model objects from the JSON, so at some point both of them must be present in memory (unless you're able to incrementally destroy those parts of the DOM that you're done with). Anyhow, IMO a proper JSON library should offer both, in a layered approach. That is, a lower level SAX-style parser, on top of which a DOM-style API is provided as a convenience.
        IshKebab 1y ago
        > since you'd most likely want to build your own model objects from the JSON, so at some point both of them must be present in memory Not really because the JSON library itself can stream the input. For example if you use `serde_json::from_reader()` it won't load the whole file into memory before parsing it into your objects: https://docs.rs/serde_json/latest/serde_json/fn.from_reader.html https://docs.rs/serde_json/latest/serde_json/fn.from_reader.... But that's kind of academic; half of all memory and all memory are in the same league.
        meindnoch 1y ago
        That's only true if your model objects are serde structs, which is not desirable for a variety of reasons, most importantly because you don't want to tie your models to a particular on-disk format.
        IshKebab 1y ago
        In the vast majority of cases you can and should just load directly into Serde structs and use those directly. That's kind of the point. In some minority of cases you might not want to do that (e.g. because you need to support multiple versions of a format), but that is rare and can also be handled in various ways directly in Serde.

IshKebab 1y ago

It also feels like only half the job to me. Reminds me of SAX "parsers" that were barely more than lexers.

flohofwoe 1y ago
I mean, what else is there to do when iterating over a JSON file? Delegating number parsing and UNICODE handling to the user can be considered a feature (since I can decide on my own how expensive/robust I want this to be).
- skydhash 1y ago
  That is what I like Common Lisp libraries. They are mostly about the algorithms, leaving data structures up to the user. So you make sure you got those rights before calling the function.
- IshKebab 1y ago
  Extracting the data into objects. Libraries like Serde and Pydantic do this for you. Hell the original eval() JSON loading method did that too.
  - meindnoch 1y ago
    Then you lose the ability to do streaming.
    - IshKebab 1y ago
      True, but usually you only need that if your data is so large it can't fit in memory and in that case you shouldn't be using JSON anyway. (I was in this situation once where our JSON files grew to gigabytes and we switched to SQLite which worked extremely well.)
      - meindnoch 1y ago
        Actually, you'll hit the limits of DOM-style JSON parsers as soon as your data is larger than about half the available memory, since you'd most likely want to build your own model objects from the JSON, so at some point both of them must be present in memory (unless you're able to incrementally destroy those parts of the DOM that you're done with). Anyhow, IMO a proper JSON library should offer both, in a layered approach. That is, a lower level SAX-style parser, on top of which a DOM-style API is provided as a convenience.
        IshKebab 1y ago
        > since you'd most likely want to build your own model objects from the JSON, so at some point both of them must be present in memory Not really because the JSON library itself can stream the input. For example if you use `serde_json::from_reader()` it won't load the whole file into memory before parsing it into your objects: https://docs.rs/serde_json/latest/serde_json/fn.from_reader.html https://docs.rs/serde_json/latest/serde_json/fn.from_reader.... But that's kind of academic; half of all memory and all memory are in the same league.
        meindnoch 1y ago
        That's only true if your model objects are serde structs, which is not desirable for a variety of reasons, most importantly because you don't want to tie your models to a particular on-disk format.
        IshKebab 1y ago
        In the vast majority of cases you can and should just load directly into Serde structs and use those directly. That's kind of the point. In some minority of cases you might not want to do that (e.g. because you need to support multiple versions of a format), but that is rare and can also be handled in various ways directly in Serde.