Re: [Json] Schemas & so on

[Phillip Hallam-Baker <[e-mail]>]

On Tue, May 3, 2016 at 1:25 PM, John Cowan <[e-mail]> wrote:

> Phillip Hallam-Baker scripsit:
>
> > I don't see any need to specify upper or lower bounds on integers. We
> don't
> > do this in C, C# or any major programming language.
> >
> > We do specify bounds on representation, int32, uint32 etc. But that is
> more
> > a matter of convenience and space management.
>
> That seems to me to be a distinction without a difference.  We need to
> specify the bounds on specific JSON numbers so that we know that we can
> safely deserialize them to language-specific types.  I agree that we don't
> need arbitrary bounds like -1..52 very much, but 0..255 is another matter.
> It would probably be enough to allow a fixed set of bounds like u8, s8, ...
> u64, s64, f32, f64.
>

Right now, my tool allows those hints to be specified when it is used to
generate TLS schema serializers/deserializers but I haven't seen the need
to use them for a JSON protocol so far.

I think syntactic sugar does actually matter. That is I see a big
difference between something like

int MyField;

and something like this

{"MyField" : { "type" : "Integer", "max" : 42, "min" : -32 } }

I think the chances of spotting a blooper in the second is a lot better.


If I ever did another revision to my tools to put all of the parsers into
one system, it would probably have an input language that was something
like the following:

MyStruct Class
    MyIntField Integer
    MyStringField String

If I then wanted to specify representation it would probably be by
subtyping 'Integer' to allow int8, uint8, ... int64, uint64 like you
suggest.

Right now, the only case where I see a need to call something out as a
special case is for handling BigNums. We use those a lot in Crypto but it
is a real pain to use a generator where every Integer is a bignum by
default. It is also inefficient as you have to convert your bignum to
decimal and back.

The reason for having the 'label before declaration' rule is that it
provides consistency. Every definition has the label first. C has a nasty
habit of doing this differently for classes and fields/variables. Doing it
the same way throughout is much cleaner. The label should go first because
it is always one token while the definition may be a structure.