On Monday, 25 August 2014 at 20:21:01 UTC, Sönke Ludwig wrote:
Well, of course it's based on that RFC, did you seriously think
something else?
I made no assumptions, just responded to what you wrote :-). It
would be reasonable in the context of vibe.d to assume the
ECMAScript spec.
But I generally agree, it's just that the anti-exception voices
are pretty loud these days (including Walter's), so that I
opted for a non-throwing solution instead.
Yes, the minimum requirement is to just get "did not validate"
directly as a single value. One can create a wrapper to get
exceptions.
I guess it wouldn't hurt though to default to throwing an
exception, while still providing the
GeneratorOptions.specialFloatLiterals option to handle those
values without exception overhead, but in a non
standard-conforming way.
What I care most about is getting all the free validation that
can be added with no extra cost.
That will make writing web services easier. Like if you can
define constraints like:
- root is array, values are strings.
- root is array, second level only arrays, third level is numbers
- root is dict, all arrays contain only numbers
What is a bit annoying about generic libs is that you have no
idea what you are getting so you have to spend time creating dull
validation code.
But maybe StructuredJSON should be a separate library. It would
be useful for REST services to specify the grammar and
auto-generate both javascript and D structures to hold it along
with validation code.
However, just turning off parsing of "true", "false", "null",
"[", "{" etc seems like a cheap addition that also can improve
parsing speed if the compiler can make do with two if statements
instead of a switch.
Ola.
