JSON: Change properties key to _properties_ to reduce chance of conflict

[maxpowa]

Relates to #4595, _properties_ is less likely to conflict than properties is.

[yxhuvud]

Does %properties work for macro arguments?

[maxpowa]

Nope, syntax error.

[straight-shoota]

That wouldn't make sense, because the macro argument properties is a macro-level variable, whereas %-prefixed variables are local variables in the generated code. This are two different levels.

[yxhuvud]

Well, it obviously doesn't work, but it is unfortunate that it is impossible to avoid collisions.

[luislavena]

Thanks for your contribution @maxpowa!!!

It seems that CI failed due differences in the format.

Can you make sure crystal tool format is run on the code and push again?

For more details, please see the documentation about coding styles

Thank you!
❤️ ❤️ ❤️

[asterite]

Thank you! But we still have this problem with the strict property, though I don't know how to solve that. In any case, one can pass a Hash or NamedTuple to avoid clashing with properties or strict, so this change is not strictly necessary, but still welcome.

[straight-shoota]

@asterite I don't think strict is really an issue. In order to use this, you need to provide the properties as a NamedTuple/Hash literal anyway. It can't be used as a positional argument because JSON.mapping(title: String, true) is invalid - and JSON.mapping(title: String, strict: true) is interpreted as one NamedTupleLiteral.

It would perhaps be possible to introduce a special check if _properties_ is a NamedTupleLiteral and it's last key is strict with a BoolLiteral value. But that would make the code much more complicated with IMHO little improvement to be able to use JSON.mapping(title: String, strict: true) instead of JSON.mapping({title: String}, strict: true).