std.data.json formal review

Sönke Ludwig via Digitalmars-d digitalmars-d at puremagic.com
Wed Aug 12 00:19:04 PDT 2015


Am 11.08.2015 um 23:52 schrieb deadalnix:
> On Tuesday, 11 August 2015 at 21:27:48 UTC, Sönke Ludwig wrote:
>>> That is not going to cut it. I've been working with these for ages. This
>>> is the very kind of scenarios where dynamically typed languages are way
>>> more convenient.
>>>
>>> I've used both quite extensively and this is clear cut: you don't want
>>> what you call the strongly typed version of things. I've done it in many
>>> languages, including in java for instance.
>>>
>>> jsvar interface remove the problematic parts of JS (use ~ instead of +
>>> for concat strings and do not implement the opDispatch part of the API).
>>>
>>
>> I just said that jsvar should be supported (even in its full glory),
>> so why is that not going to cut it? Also, in theory, Algebraic already
>> does more or less exactly what you propose (forwards operators, but
>> skips opDispatch and JS-like string operators).
>
> Ok, then maybe there was a misunderstanding on my part.
>
> My understanding was that there was a Node coming from the parser, and
> that the node could be wrapped in some facility providing a jsvar like API.

Okay, no that's correct.

>
> My position is that it is preferable to have whatever DOM node be jsvar
> like out of the box rather than having to wrap it into something to get
> that.

But take into account that Algebraic already behaves much like jsvar (at 
least ideally), just without opDispatch and JavaScript operator 
emulation (which I'm strongly opposed to as a *default*). So the jsvar 
wrapper would really just be needed for the cases where really concise 
code is desired when operating on JSON objects.

We also discussed an alternative approach similar to 
opt(n).foo.bar[1].baz, where n is a JSONValue and opt() creates a 
wrapper that enables safe navigation within the DOM, propagating any 
missing/mismatched fields to the final result instead of throwing. This 
could also be combined with a final type query: opt!string(n).foo.bar


More information about the Digitalmars-d mailing list