Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Swift] Reference in Object API to underlying type #6058

Closed
jackflips opened this issue Aug 3, 2020 · 8 comments · Fixed by #6059
Closed

[Swift] Reference in Object API to underlying type #6058

jackflips opened this issue Aug 3, 2020 · 8 comments · Fixed by #6059

Comments

@jackflips
Copy link

Would it be possible to have a reference to the underlying FlatBufferObject type in its generated convenience class?

For example, if I have a Request type, and I pass in --gen-object-api to the FlatBuffer schema compiler, I get a RequestT class. I think it would be really nice to have a reference to the Request type in the RequestT class, so that I could write an extension on RequestT that would let users call serialize() and have it spit out FlatBuffer Data, without having to worry about how FlatBuffers work at all.

@mustiikhalil
Copy link
Collaborator

mustiikhalil commented Aug 3, 2020

@jackflips thanks for opening the issue. I think the serialize method you are mentioning already exists.


        var monster = Monster.getRootAsMonster(bb: fb)
        readFlatbufferMonster(monster: &monster)
        var unpacked: MyGame_Example_MonsterT? = monster.unpack()
        readObjectApi(monster: unpacked!)
        var builder = FlatBufferBuilder()
        let root = Monster.pack(&builder, obj: &unpacked)

So you can write an extension that does the following:

func serialize() -> Data {} 

@jackflips
Copy link
Author

Makes sense! But the serialize extension would have to be on Monster, right? Rather than MonsterT?

@mustiikhalil
Copy link
Collaborator

@jackflips.
The extension is going to be on MonsterT, and it would be something like this:

func serialize() -> ByteBuffer {
  var builder = FlatBufferBuilder(initialSize: 64)
  let root = Type.pack(&builder, obj: &self)
  builder.finish(root)
  return builder.sizedBuffer
}

more or less it should look like this, which gives me the idea of actually adding this method to the ObjectApi protocol, instead of letting the users have the control over it.

@jackflips
Copy link
Author

jackflips commented Aug 3, 2020

On my generated PacketT object (analogous to MonsterT), I don't have a pack function. Pack is a static function on the Packet class. This brings me back to my original question, which is how can I access the Packet class from PacketT to use Pack? Your example seems to imply that pack is a function on MonsterT.

more or less it should look like this, which gives me the idea of actually adding this method to the ObjectApi protocol, instead of letting the users have the control over it.

That's a great idea.

@mustiikhalil
Copy link
Collaborator

so, pack is indeed a Monster static function, and you can't access it through MonsterT. since if you see the example let root = Monster.pack(&builder, obj: &new_T_object) we pack the new_T_object by passing it with the builder into that function. So the object Api objects don't hold any reference to the original buffer since they are unpacked objects, however, you can pack them back to a new buffer by using the pack function. I will add a wrapper function to ease the transition for that.

@jackflips
Copy link
Author

however, you can pack them back to a new buffer by using the pack function. I will add a wrapper function to ease the transition for that.

I'm confused about this. How am I supposed to call the pack function from an extension on NativeTable? I see the ObjectAPI protocol definition in the FlatBufferObject.swift file but it doesn't seem like any of the generated code conforms to this protocol.

@mustiikhalil
Copy link
Collaborator

@jackflips I created the PR, you can take a look at the solution there. plus if you want it urgently you can adapt that solution into your own extension.

@jackflips
Copy link
Author

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants