Subject: [Json] Doofus Parameter Labels

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 30 Mar 2015 15:38:39 -0400

So, I am implementing an IETF draft which is fairly widely used and
using a code generator to speed things along.

The code is breaking because the spec has decided to use 'protected'
as a tag which is of course a reserved keyword in Java, C# and much
else.

OK so there is an escape feature that I can use instead. But those
don't exist in other languages. And then I come across a tag that has
a non alphanumeric tag value.

This sort of thing is likely to be happening quite a bit now that
people are using JSON and it would be a lot better if we could avoid
it. The fact that JSON allows tags to be any valid UNICODE sequence
does not mean that all choices are equal.

In general it would be good if people writing specs could stick to the
identifier naming rules for C and avoid reserved words from Java, C#,
etc. The languages and tools I use are quite capable of using accented
characters. I have absolutely no clue how to generate them on the
keyboard though.

---

From: Wendy Roome <[email-masked]>
Date: Mon, 30 Mar 2015 16:04:32 -0400

It would help if you told us which draft and which code generator you are
using.

My first reaction is that if the code generator is supposed to generate
real code that you can feed directly into a compiler, then the code
generator should ensure that it generates legal code. Eg, if it maps a
protocol field into a variable, the code gen should transmogrify the
protocol field name into a valid variable name. Simplest solution is to
slap a fixed prefix, like m_, onto every generated variable, and replace
non-alpha-num chars with _.

My second reaction is why can¹t you do that yourself?

	- Wendy Roome

On 03/30/2015, 15:38, "Phillip Hallam-Baker" <[email-masked]> wrote:

>_______________________________________________
>json mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/json

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Mar 2015 15:15:35 -0500

> a non alphanumeric tag value.

This sort of question comes up a lot for jq.  I don't think you can
produce a generic rule here.  "protected" is a keyword in many
languages, but not others.  It's not a keyword in jq, for example,
though 'reduce' is (which is probably not a keyword elsewhere).

There is a workaround, of course.  Instead of writing

    .then.protected

one has to write

    .["then"].protected

or

    ."then".protected

in jq in order to access the value at the "protected" object name in the
object at the "then" name in the top-level object.

What sort of rule do you have in mind for avoiding this?  Why are the
workarounds insufficient?

> does not mean that all choices are equal.

There are other considerations too.  For example: names shorter than 8
or 16 bytes may get treated as immediate values, without heap allocation
(I have a half-baked patch to do that for jq) in some implementations.
(E.g., a NaN-coding implementation may be able to store most 7-byte
strings as immediate values.)

> characters. I have absolutely no clue how to generate them on the

OK, so, stick to identifier naming rules for C, avoid keywords from some
set of programming languages, and don't use non-ASCII characters.  How
do we specify such constraints?  Remember, programming language specs
evolve and tend to grow new keywords.

-1

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 30 Mar 2015 18:35:47 -0400

> It would help if you told us which draft and which code generator you are

The draft is water under the bridge at this point. The code generator
is ProtoGen.

> protocol field name into a valid variable name.

The issue is not the difficulty of transmogrification in the
generator, it is remembering what the transmogrification is in my
head.

Programming is a process of getting ideas into electronic form. The
more unnecessary hoops people have to jump through, the greater the
probability of error.

> Simplest solution is to

The problem comes when you are using two code generators that have
different ways of coping with the problem.

The choice of labels is arbitrary. Why make choices that introduce
unnecessary complexity?

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Mar 2015 18:20:39 -0500

> The choice of labels is arbitrary. Why make choices that introduce

Because we can't predict what all those names will be.