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

Serialize Generic Map as MessagePack map type #8

Open
krisbitney opened this issue Aug 15, 2023 · 0 comments
Open

Serialize Generic Map as MessagePack map type #8

krisbitney opened this issue Aug 15, 2023 · 0 comments

Comments

@krisbitney
Copy link

https://www.notion.so/polywrap/934502fd65c94d85a80358fa5fd785f2?v=fc823028892c456ca5a228e422474d36&p=32524b44a90c40fb984d723757d478ab&pm=s

In MsgPack, we currently serialize Map<K,V> as an object by default, and as an extension type when it should be treated as a Generic Map. How to treat it depends on context. This works in JavaScript (and maybe Python). In statically typed languages like Rust, Kotlin, and Swift, solutions are more complicated.

In Kotlin and Swift (and originally in Rust), users must wrap their Map in a GenericMap class so it can be serialized as an extension type.

In Rust, a custom implementation of the serde msgpack package was written to avoid this sort of behavior. (This can also be done in Kotlin in the future, but is unnecessary if this idea is executed.)

However, it is possible to simply always serialize Map without using extension types.

When we serialize an object to MsgPack, we are actually serializing the object using MsgPack’s Map format. This works because an object is a set of key-value pairs. Because we were doing that, we decided to treat actual maps as a MsgPack “extension type”.

If we were to serialize both Map and Object types using the MsgPack Map format, we could still distinguish between them. Wraps would still know how to serialize and deserialize each type because the wrap bindings are generated from the schema.

This change would improve the UX for app and plugin developers using statically typed languages like Kotlin, Swift, possibly Rust, and any others we support in the future.

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

No branches or pull requests

1 participant