Override = operator for assignment of std vector and map to JSON value objects

Allow the option to directly assign std vector or array to a json value array type.(no need to use append and a loop) and the same can be said for std map

[BillyDonahue]

"Append and a loop" is obviously inconvenient. It's not clear that a std::map or std::vector should be the only kinds of associative container or sequence that should get this special treatment. We should not be in the business of making lists of special supported container types. I would then like to offer a proposal to use something other than operator= for this assignment operation, which would more explicitly annotate the call site with intent and take the guess work out of determining what kind of Json::Value postcondition is intended.

If all you need is something better than "append and loop", that should suffice.

Of course std::map and std::vector should not be the only ones given any preferencial treatment.

As for a matter of convenience am looking at both creation of Json::Value object and conversion from json::value object to std::map, std::vector or any appropriate container for said type.

@BillyDonahue any direction or thoughts on this ?

I could work on a pull request, though would love to know what direction it would take.

[BillyDonahue]

I wasn't clear on what your specific proposal would be.

@BillyDonahue I am proposing a constructor for Json:: Value that takes vector and makes a JSON array, or takes a map and makes a Json::Value object.

Initially makes sense to only support three containers vectors, maps and arrays since they directly translate to json types.

If any work is being done on the Thing API then this and the reverse conversion would technically be covered under that, though this should simplify a use case.

[BillyDonahue]

@BillyDonahue I am proposing a constructor for Json:: Value that takes vector and makes a JSON array, or takes a map and makes a Json::Value object.
Initially makes sense to only support three containers vectors, maps and arrays since they directly translate to json types.

That's where I don't agree. vector, maps and array do not directly translate to json types in a 1:1 sense. I know what you mean by that, but the technicalities are important here. There are lots of kinds of sequences in C++, and lots of kinds of associative containers, ordered and unordered. JSON map keys can only be strings, but C++ can use anything as a key if the proper functors are given. JSON objects can recursively contain JSON objects. It would IMO be going too far to make constructors supporting recursive conversions, but it would also be logically inconsistent not to support them.

These very logical kinds of conversion sound like good proposals for Json::Value -yielding factory functions, but not constructors built into the Value class.

If any work is being done on the Thing API then this and the reverse conversion would technically be covered under that, though this should simplify a use case.

What's the "Thing API"?

PS: Can you see why I'm confused about the proposal? Initially you suggested support for assignment, but now you're proposing constructors. A little later you said you wouldn't prefer vector or map, supporting rather "any appropriate container", but now you seem to be only proposing support for converting from vector, map and array to Value. Really need a specific proposal to discuss.

The fact of the matter is I don't really have a proposal but a usecase that I want to solve.

Was really hoping for some help on a way to fix it for me that could then be a part of this library.

Also the thing API is what I got from reading
#423

[cdunn2001]

For changes to the master branch, I completely agree with @BillyDonahue.

The "New Thing" would use template arguments for data types: Int, String, and Float. I suppose it could also let the underlying array and map types be specified, so maybe your idea could apply there somehow. However, there are so many Json libraries available that I wonder whether you might be better off simply using one of them.

OTOH, we could add convenient wrappers, in a separate include file. Please submit a PR if that's really what you want.

[nickion]

I'd encourage considering something that while inevitably not covering all conceivable cases, will serve at least the most useful ones. As an example PoC, if jsoncpp is updated to allow type casts for some common types, e.g.:

operator bool() const { return asBool(); }
operator float() const { return asFloat(); }
operator double() const { return asDouble(); }
operator int() const { return asInt(); }
operator const std::string() const { return asString(); }

a function such as this is then possible

template <class T> void json_to_container(const Json::Value& val, T& res)
{
    if (!val.isArray()) {
        throw std::runtime_error("Value not an array");
    }

    for (Json::Value::iterator iter = val.begin(); iter != val.end(); iter++) {
        res.push_back(*iter);
    }
}

res could be any of several useful container classes such as vector, list, deque etc., containing items of several possible types. Refined and made as a method, perhaps with variants that return a bool rather than doing a throw and that accept a default, would certainly make usage more convenient and enjoyable.

[cdunn2001]

In 2.0, cast operators might be interesting. For now, they could alter behavior of existing code, so I think we'd have to be wary.