Schema and code generation extensions

[Alberto Fernández]

Hi,

I've been playing with the FlatBuffer project lately, and I found that it's simplicity, in both syntax and source code, is a good fit for one of my projects. However, I need to extend it's capabilities for my specific needs and I would like some guidance. I would prefer not to fork the main repository because I would be making big disruptive changes in the parser / code generation and integrating with upstream in the future looks troublesome.

I was thinking about making some kind of generic parser and code generation "extensions", which are generic and allow anyone to use flatbuffers as a library to integrate custom schema extensions and arbitrary code generation. Are you guys working in something similar at the moment or is it in the roadmap? Would such a change be welcome in the main repo? If yes, I would like some guidance in how to approach it, both architecture and implementation-wise. If not, what do you think would be the best solution for my problem?

Thanks in advance!

Regards,
Alberto

[Wouter van Oortmerssen]

Not sure what schema extensions you want to make, but we already have the concept of attributes that allow adding additional metadata to fields etc, which can be queried by code generators.

@Lakedaemon on github is already doing some refactoring for all our code generators, it be good to check your plans with him too.

So far all code-generators are part of the main project, but I am not against the idea of code-generator plugins loaded over a .dll/.so. Though if you want to write fully independent code generators, even easier would be to use the reflection interface in C++, since that means it can be a separate executable.

--
You received this message because you are subscribed to the Google Groups "FlatBuffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alberto Fernández]

Hi Wouter,

you were right. Our needs are a bit out of the scope of the project, so it is questionable at best such modifications to the parser / code generation to support a more generic approach. For the time being we have forked the project and made the minimal changes in it's core in order to support our needs and keep updated from upstream with minimal friction.

Thanks for your reply,
Alberto