Make property renaming optional

[TJKoury]

I am integrating Flatbuffers with existing data standards, it is mandatory to use the exact property names / namespaces contained in these standards going forward, including all capitalization.

I've hacked in a quick fix to remove MakeCamel, MakeScreamingCamel, and MakeCamelCase, as well as disabling this warning. I can work on a pull that puts disabling these behind a flag, for users in my situation, if it is something that would be accepted.

[dbaileychess]

I would be open to this, but not as a flag, but an attribute in the schema file itself. Something like

SomeSchema.fbs

attribute "keep_naming"

table A {
soMeFunkyNam_ing: int (keep_naming)
}

This way the schema is explicitly opting out of the style guide and clearly states that.

If it was a flag option, I think it would be confusing.

[TJKoury]

That is an interesting option, and makes the implementation more portable.

[Bklyn]

I like the idea of an attribute, but I guess I'd need to decorate every struct/table/enum with this (hopefully not every field!). Are file or namespace-scope attributes possible?

[TJKoury]

I think he’s talking about a schema-level flag, at the top of the file, stating that everything within it should not be altered. This is good, since it improves portability: if I give you a schema, you should be able to reproduce the code without knowing what flags I used.

[Bklyn]

Wait, why are you closing this issue? Now there's no open issue for this feature request AFAIK since I closed #7128.

Attributes can be applied to fields or types (i.e. struct, table, enum). I don't think they can be attached to a schema presently, but I agree this would be the most useful scope for using this approach.

[TJKoury]

I agree, let’s keep it open and flesh out an implementation.

[dbaileychess]

Our parser does handle file-level attributes, but that is mostly for use in reflection as the code generators won't know what to do with it. I would probably want to leave that as is.

We also have a special native_include identifier that is top-level, so we could do somethin similar if we had too.

I am thinking we should introduce a pragma concept, as a way to tell the flatc compiler how to generate the code. Thus this feature would be something like:

-- some.fbs

pragma keep_identifier_naming

table inTerestingNaMing {
  s-o-m-e-ODDBALLfield:int;
}

And everything under the pragma (lexical scope) would use the specified naming and not modified it at all.

Individual generators would be free to ignore the pragma command, that way we don't have to implement this feature for all languages at once.

We would also probably need to add a new attribute to override this, something like: default-naming

-- some.fbs

pragma keep_identifier_naming

table inTerestingNaMing {
  s-o-m-e-ODDBALLfield:int (default-naming);
}

And the field tagged with default-naming will always use the language specified default.

Thoughts?

[Bklyn]

Thoughts?

Sounds good to me.

[TJKoury]

I like it, though the “default naming” might be overkill / confusing. I envision this pragma to be used for compatibility purposes like my use case, tagging individual fields might lead to some confusion if the override pragma is missing.

[CasperN]

IMO, it would be better to just not support global "keep_naming" + opt out logic, since its such a niche use case... its not too hard for a minority of users to type (keep_naming) everywhere they need.

If we do go ahead with pragmas and stuff, the parser should contain this logic so that from the code generators' perspective, its as if the user typed (keep_naming) on all fields.

I also wonder if this feature will expand, maybe people would want to (keep_naming) for some languages and not others? Maybe they'll want to override our ideas of when to use CamelCase vs snake_case... I doubt fine grained configurability is worth the complexity, but if it turns out to be, we should do a little upfront design.

[TJKoury]

In my opinion, having different conventions per-language sort of defeats the interoperability; language agnostic inputs / outputs like the IDL and the typed JSON Schema output should reflect what you expect no matter what language you use. Otherwise you are stuck trying to translate field names according to a rule set that’s only available inside the binary.

[dbaileychess]

In my opinion, having different conventions per-language sort of defeats the interoperability; language agnostic inputs / outputs like the IDL and the typed JSON Schema output should reflect what you expect no matter what language you use. Otherwise you are stuck trying to translate field names according to a rule set that’s only available inside the binary.

I disagree. The schema is the interoperable part, the individual languages should conform to their own conventions. You don't really have to translate field names with some obscure rules; it just simple formatting changes that should be self-evident.

IMO, it would be better to just not support global "keep_naming" + opt out logic, since its such a niche use case... its not too hard for a minority of users to type (keep_naming) everywhere they need.

That is also fine with me, since it's the easiest thing to do and rationalize.