Re: [Boost-users] [property_tree] Parsing JSON

Subject: Re: [Boost-users] [property_tree] Parsing JSON
From: Bryce Lelbach (admin_at_[hidden])
Date: 2011-01-04 09:02:01

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 2 Jan 2011 20:05:32 +0100
Olivier Tournaire <olitour_at_[hidden]> wrote:

> OK. So, right now, nothing to acceess the parsed JSON structure. Am I right?

I'm almost done with read-only access. ATM a mutable accessor would be a bit more
complex to implement.
 
> Yes, I like this kind of STL-like access.

On second thought, I've decided I don't like the STL-like access, because it's
dangerous, and/or requires boilerplate code to make nested calls (such as
js["results"]["artworkUrl100"]) safe.

Instead, I've written a simple Boost.Proto DSEL for access, so accessing the
node in question would look like:

std::cout << (js/"results"/"artworkUrl100") << std::endl;

std::cout << (js/1/4) << std::endl;

The json_ir operator/ takes a proto expression and returns a proto terminal.
The proto DSEL's expression wrapper has an operator utree and streamable ops.
Instead of throwing or seg faulting on a failed chain access (for example, if
there was no "results" member), this method of access will always return a utree;
if a failure occurs, an invalid_type utree node is returned.

> std::cout << js.get<value_type>("results.artworkUrl100") << std::endl;

There is no need to do this; as mentioned above, code that requires checking
(aka code that code fail or throw) is undesirable. I have no intention of
emulating what I view as property tree's failures.

The js object's accessor would return a utree node, and the utree class does
have a get method, but it is not advisable to use it. It is safer to write a
visitor class, because such a class will fail to compile if you do not have a
default case (aka `template<class T> result_type operator() (T) const { ... }')
or handle every possibility in the visitor.

Also, utree is streamable, and has a number of sane operator overloads (for
example, arithmetic operators are overloaded so that you can do math with utree
arithmetic nodes. Probably, we should overload operator+ for strings or something).

> And what about an access via index:

As I mentioned in my follow up email (and in the above example), this will be
possible. 

I suspect to have a complete prototype by the end of the day. Major dependencies:
Spirit, MPL, Fusion, Proto, Multi-Index, Variant.

- -- 
Bryce Lelbach aka wash
boost-spirit.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk0jKFkACgkQ9cB/V3/s9EyjngCeM1eBUhaJTwzBfdLiggWnAp+l
wZEAnj66yv93w7n+QhUQaIntf+FiFW66
=k2jk
-----END PGP SIGNATURE-----