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
