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.
