I'm -0.5. We never got it merged but I think at least some people might be relying on JSON serialized versions of flatbuffers schemas (and I would guess this would break that, or at least it is something we should test). While I like consistency and the warnings might be annoying, I'd rather keep it the way it is as I think the effort to fix (and potential impact) outweighs the benefits.
On Mon, Aug 2, 2021 at 6:34 AM Antoine Pitrou <anto...@python.org> wrote: > > While I'm not fond of changing naming conventions because of a > third-party project, in this case we have inconsistent naming in our > .fbs files, so this could be an opportunity to clean it up. > > > Le 02/08/2021 à 15:00, Wes McKinney a écrit : > > While doing some Flatbuffers work, I noticed that recent compiler > > versions now warn about non-snake-case field names: > > > > https://github.com/google/flatbuffers/pull/6005 > > > > It seems that the intent is for the compiler to generate > > "language-friendly" code (e.g. camelCase for Java) from snake_case > > schemas. It looks like Arrow won't be disrupted by this warning, but I > > am wondering if this is something that we might be able to fix at some > > point. Because the field names do not impact the binary format of the > > Flatbuffers, this would be backward and forward compatible, but it > > would require some code changes in various bindings (e.g. C++, but > > probably not Java). > > >
