Replies: 1 comment
-
Thanks for bringing this up and sharing your use case! I think it’s best to keep serialization outside of the package. The main focus here is to provide a fast and efficient in-memory adaptive radix tree and adding built-in serialization would add complexity and lock users into a specific format. Different users have different needs: some might use gob, others JSON, or even protobuf, so keeping it separate gives everyone the flexibility to choose what works best. Another challenge is that the library allows you to store any type of value This isn’t the first time serialization has come up, and if you check other refs to this package, you’ll see a few examples where users implemented their own serialization methods. That might give you some ideas or shortcuts for your use case. If you end up building a helper for this, I’d love to take a look, give feedback, and even mention it in the package’s docs as a helpful example for others. Let me know if you need any input! |
Beta Was this translation helpful? Give feedback.
-
I've got a use-case where I need to persist and object, that includes a tree from this module, onto durable storage and is therefore looking for ways to encode and decode a tree to and from a binary representation.
While my use-case evolves around writing to storage, I could imagine a similar use-case for others where a tree must be send over the wire in a digital representation.
Would this be a feature that could be implemented in this library?
Since I'm writing the code anyway, I figured I'd ask if this is something that would make sense to contribute back to the library.
What I'm looking at right now is encoding it with the gob encoding rules, but I'd be open to discus other encoding schemes.
Beta Was this translation helpful? Give feedback.
All reactions