FlexBuffers ("Schemaless FlatBuffers") part of master now.

[Wouter van Oortmerssen]

Just merged it onto master:

https://github.com/google/flatbuffers/commit/aac6be1153eb5343f03dd60101ee438636e9300b

It's had a fair few changes, including a binary incompatible change since some of the versions available on the "schemaless" test branch. Now that it is on master however, binary format changes are to be avoided at all cost, unless it is a major problem.

Does that mean you can start using it in production? Depends on your courage. This is still early days and bugs are not impossible. Testing could still be more thorough.

That said, please put it through its paces. While I hope the binary format is locked, the API and implementation details may still change, so if you spot problems, let me know.

[Arun Sharma]

Nice. Question about the implementation:

Why isn't the Reference a subclass of Object?

The reason I ask is - doing so will enable writing a visitor over an Object for conversion into dynamics such as folly::dynamic or iterlib::dynamic.

Sample code:
https://github.com/adsharma/flatbuffers/commit/1fddcd79a794972cd4e89bc612f604dcbb2282a8

Ideally, I'd like such conversion to be lazy. If there is a large object and I'm only interested in a small part of it, I'd like to pay the cost of parsing/converting only the interesting parts.

[Wouter van Oortmerssen]

Arun,

They have different roles. A Reference is a handle to ANY value, and you don't necessarily know what that is.

An Object is the root of all vectors and maps, but not of scalars. Scalars are just themselves.

This separation is such that any functions that look up a new value can return a Reference, and that all code that figures out what type something is can be in Reference, and is not duplicated among the various kinds of containers.

So to implement your object visitor pattern, you can implement a dispatcher on Reference, and not on anything else.

We could make Reference a subclass of Object purely in the sense that they share similar instance variables, but really they are different things. Maybe I should make Object private, since I don't see any reason for anyone to be needing to use it.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Maxim Zaks]

I also pushed FlexBuffersSwift to a new github repo.

It is still work in progress but it is already usable and testable

https://github.com/mzaks/FlexBuffersSwift

[Wouter van Oortmerssen]

Code on first glance looks similar to the C++ one, which is good!

Note that you started making this port with one of the "preview" commits, and some incompatible changes to the encoding have been made since (mainly in the type enum). So you may want to go through the C++ code and double check your code corresponds. Now that it is part of master, future changes are meant to all be strictly backwards (and almost always also forwards) compatible.

As I said with your other Swift port, I suggest you start working on a PR to have this merged into FlatBuffers.

--

[Maxim Zaks]

Hi Wouter,

thanks for taking the time to look through the code.

When I was porting I actually went through different cases and wrote unit tests to make sure that the binary is equal to the result in C++. 

However you are right, I did it quite early. So will go through the tests again and compare them with C++ results.

To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers...@googlegroups.com.

[chandra]

This is great folks. Any chances of a Golang implementation guide?

[Wouter van Oortmerssen]

Chandra: I know very little Go, so all I can say is "try to follow the C++ implementation as closely as possible". Note that https://google.github.io/flatbuffers/flatbuffers_internals.html has a section on FlexBuffers in particular that may prove helpful.

--

[chandrakanth n]

thanks Wouter. Will try to follow the C++ implementation.

To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers+unsubscribe@googlegroups.com.