On 4/29/20 2:12 PM, Brian Padalino wrote:
> On Wed, Apr 29, 2020 at 1:57 PM James Kulp <jek_at_parera.com
> <mailto:jek_at_parera.com>> wrote:
>
> The simplest thing I can think of (i.e. short term easy/doable),
> is an option when property values are being retrieved as text, to
> have an option to produce a json string rather than the "native"
> text format. This requires no library.
>
>
> Just curious, why are you against the MIT licensed library I posted:
>
> https://github.com/nlohmann/json
>
> It's a single header file you include, so no extra recompilation and
> it's very liberally licensed so you can modify it all you want
> without any issues.
>
> Also not sure why getPropertyJSON() would be a bad addition to the
> API? I guess multiple ways to get text could be problematic or ambiguous?
That is pretty much what was proposed. There is no being "against" that
library, its just that the binary-to-text conversion does not need a
library since given the simplicity of JSON syntax, it wouldn't help
since its just a simple textual serialization of existing internal data
structure. Plus it would allow developers to use whatever library they
wanted.
OTOH, going the other way would be best done with a library, and the one
you like seems just fine, and binary-to-binary conversion could easily
use the library, which would then get the serialization for free.
>
> Since the native text format is more strongly typed, its a bit
> harder to go in the other direction, and would require choosing a
> library and dealing with various type ambiguities.
> Just a bit more work.
>
>
> It also seems very well documented, like the basic usage here for
> going back and forth between types:
>
> https://github.com/nlohmann/json#basic-usage
>
> Either way, I appreciate the answers you guys have given and the fact
> I can retrieve the whole string in a single read is great.
>
> Thank you very much.
>
> Brian
Received on Wed Apr 29 2020 - 19:20:54 CDT