mzaks
commented
6 years ago Sorry for the very late response. Codable support can be introduced as a separate project based on the FlatBuffersBuilder and FlatBuffersReader class. However I don't see me doing it any time soon. First I don't have much experience with Codable and I also don't need it currently. That said I am also concerned with the semantics of Codable solution. In FlatBuffers the point of truth is the schema. In a Codable solution the point of truth becomes the class declaration itself. In order to support evolutions (change of type definitions) the user would have to be very careful, not changing the field declaration order, renaming but not removing the "deprecated" fields and adding new fields only at the end of the class definition. You might solve it by introducing some kind of KeyEnum where user can define mapping between property and the table index, but this seems much more complex to me than just using fbs files and do code generation.
I understand that the current way of code generating is opaque for Swift developers, this is why I started the code_gen branch (https://github.com/mzaks/FlatBuffersSwift/tree/code_gen) where I implemented FBS parser and code generator in Swift. Sadly it is not 100% done yet. I still do not cover the case with recursive table definitions, but everything else should work fine.
Also if anyone still wants to implement Codable solution I would gladly help, I just don't see myself doing it.
Hi Maxim, I really like the concept of FlatBuffers 😍 With Swift 4 you can create your own Encoder and Decoder to support the new codable feature of Swift 4. This will allow FlatBuffers to be used on a larger scale. Here some resources to help you:
FlatBuffers should also be available on most environments. For that it would have to be a cross-platform component. 😉 To create a cross-platform component your can follow my tutorial Swift Cross Platform Framework or directly use my tool XcodeTool - Create a new component cross-platform