std.data.json formal review

[deadalnix via Digitalmars-d]

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.

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.