linking types between libraries

[Roger Alsing]

Lets say I make a framework for Golang.

Where the framework have a type, "Point" which is a flatbuffer generated type.

Then lets say that some user of my framework creates his own type in some app, "Line" which might consist of two "Point"s

Can flat buffers handle linking of types this way?

If the user simply provide my frameworks flatbuffer files, he will get his own copy and generated code for "Point"

Can I somehow make an import so that the generated code knows about my framework code?

I hope I managed to describe the problem :-)

[mikkelfj]

On Thursday, April 21, 2016 at 4:32:04 PM UTC+2, Roger Alsing wrote:

Lets say I make a framework for Golang.

Where the framework have a type, "Point" which is a flatbuffer generated type.

Then lets say that some user of my framework creates his own type in some app, "Line" which might consist of two "Point"s

Can flat buffers handle linking of types this way?

Yes. FlatBuffers maps inflight data to language native types. If your language of choice supports composable types, you can, but obviously you will not get a Line object in the FlatBuffer itself, nor will you get a seamless experience since the methods applicable to your "Line" type may differ from storage and retrieve centric methods on the FlatBuffer generated types. I would say it is best to either use the Flatbuffer objects as is, and define composable types within Flatbuffers and add "Line" to the schema, or alternatively hide the FlatBuffer types from the surface API of your solution. In either case FlatBuffers provide type safety for the compound type to the extend the language and the codegenerator for that language supports it.

> If the user simply provide my frameworks flatbuffer files, he will get his own copy and generated code for "Point"

> Can I somehow make an import so that the generated code knows about my framework code?

No. You can extend types around FlatBuffer types, and that framework can load FlatBuffers fairly trivially, but you cannot make FlatBuffers know about your type extensions. It is the other way around. But that is not really an issue. You just provide our framework with whatever API you like to your end users, and also provide a load function to populate your underlying FlatBuffer types (or rather provide navigating logic since you don't actually load data). Then, with that in place, you can distribute FlatBuffer files that has no knowledge of your framework, and still make it work there, as well as in other custom frameworks that share the same underlying FlatBuffer schema.