On Sun, Jan 3, 2010 at 11:00 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
> Hitoshi Harada wrote:
>> 2010/1/3 Andrew Dunstan <andrew@dunslane.net>:
>>> Hitoshi Harada wrote:
>>>> A question: Isn't there no possibility that we have our own
>>>> implementation to handle JSON (i.e. no use of external libraries)?
>>> Why should we reinvent a wheel someone else has already invented? This is
>>> what shared libraries are all about.
>> Because what we need may be another wheel nobody has already invented.
>> I don't deny to use one of external libraries but don't like to decide
>> specification by their specifications.
> OK, we really need to stop being abstract and say what operations we want.
> I think the minimal functionality I'd want is:
>
> convert record to JSON
> convert JSON to record
> extract a value, or set of values, from JSON
> composition of JSON
>
> Now all the libraries I have looked at (briefly) would require some code to
> provide for those, possibly quite a bit of code, but that doesn't mean we
> should just start from scratch and write our own JSON parser too.
I think this is really vastly overkill. The set of operations I think
we need is more like:
- given a JSON value, tell me if it's a string, number, object, array,
true, false, or null
- given a JSON object, give me the list of member names (error if it's
not a hash)
- given a JSON object, give me the member named x (error if it's not a hash)
- given a JSON array, give me the upper bound (error if it's not an array)
- given a JSON array, give me the element at offset x (error if it's
not an array)
What you're talking about may or may not be useful and someone may or
may not want to implement it, but insisting that we have to have it
for the first version of a json type seems to me to be setting the bar
quite a bit higher than necessary.
...Robert