taoensso / nippy

The fastest serialization library for Clojure
https://www.taoensso.com/nippy
Eclipse Public License 1.0
1.04k stars 60 forks source link

Question re: extending freeze/thaw #90

Closed bobfejes closed 7 years ago

bobfejes commented 7 years ago

Hi, it seems to me if you, for example:

(defrecord custom-rec [date some-vector some-custom-obj ... other custom objs ...])

and provide custom extend-freeze/thaw, you must either re-implement the freeze/thaw strategies for Date & vector that are already implemented privately in nippy's id-date & write-vec or make your code dependent on those private vars? Is that correct?

Thanks! -Bob

ptaoussanis commented 7 years ago

Hi Bob,

Sorry for the delay replying. That's correct, though I'd strongly encourage you to please never depend on any private vars.

Some options:

[1] Indeed, in many cases this'll be what you want to do anyway for max efficiency since you'll often have cases where (for example) your vectors will always be of a fixed length. Nippy's own vector storage would encode all of the vector lengths, which you might want to avoid.

Hope that makes sense? Best of luck, cheers! :-)

bobfejes commented 7 years ago

Yep, that makes sense. Thanks for the response Peter, and for sharing the project.

On Sat, Dec 17, 2016 at 4:05 AM, Peter Taoussanis notifications@github.com wrote:

Hi Bob,

Sorry for the delay replying. That's correct, though I'd strongly encourage you to never depend on any private vars.

  • Just let Nippy freeze the record without a custom type. If it's mostly made up of vectors, etc. - that might be a reasonable choice.
  • Let Nippy freeze the record without a custom type, but provide custom types (and freeze+thaw implementations) for some of the interior members as necessary. E.g. (defrecord my-rec [regular-date regular-vector my-custom-type1 my-custom-type2 ...]).
  • For maximum efficiency, you can provide a custom freeze/thaw for the entire record - and just copy any vector/date/etc. implementation stuff from Nippy's codebase that you find convenient[1].

[1] Indeed, in many cases this'll be what you want to do anyway for max efficiency since you'll often have cases where (for example) your vectors will always be of a fixed length. Nippy's own vector storage would encode all of the vector lengths, which you might want to avoid.

Hope that makes sense? Best of luck, cheers! :-)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ptaoussanis/nippy/issues/90#issuecomment-267756823, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq_YbqQ3YhTAJOTltU785IuX8sZS5J_ks5rI8HlgaJpZM4LG8WL .

ptaoussanis commented 7 years ago

No problem, cheers Bob :-)