Re: [Jsoncpp-devel] Backwards incompatible change in jsoncpp 64-bit support

[Baptiste L. <bap...@gm...>]

2011/5/25 Stephan Beal <sg...@go...>

> On Wed, May 25, 2011 at 4:56 PM, Baptiste Lepilleur <
> bap...@gm...> wrote:
>
>>
>>> This is that feature that allows the following usage:
>>
>> Json::Value array;
>> array.append( 1234 );
>>
>
> That means a null value is effectively mutable, and only arrays/objects are
> mutable in JS (JSON doesn't describe mutability, and it has no operators
> which would allow mutation).
>

The Json::Value is mutable and provides and operator = (Json::Value is not
supposed to be dynamically allocated). There is a Json::Value::null
constant, but its usage is not enforced at the current time.


>
> Maybe we should introduce a distinction between "default" initialization
>> and "null", but I'm not sure how to go about that...
>>
>
> Absolutely. In the 2 JSON libs i've implemented (one in C++, one in C), the
> following values all have a corresponding static/constant Value instance
> (mainly as a memory allocation optimization):
>

The cost of creating a Json::Value instance is fairly small since for all
types with the exception of string/array/object it is just an enum and
primitive type assignment. Json::Value is just a wrapper on top of a
discriminated union.


> [...]
>
> A default-constructed Value has the undefined value:
>
> Value v; // v.isUndef() will return true
> v = Object(); // now v.isObject() will return true
>

This is something that we will need to investigate in the future. I think
that making the distinction between default construction and null value make
sense. But at the current I want to focus on making sure that 64 bits
integer support is in good shape before making other API changes.

Thanks for you feedback, it's interesting to see what other API are around
there.

Baptiste.