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

non-global-extensibility #23

Closed
gfredericks opened this issue Oct 4, 2015 · 10 comments
Closed

non-global-extensibility #23

gfredericks opened this issue Oct 4, 2015 · 10 comments

Comments

@gfredericks
Copy link

This is basically the exact same issue as dakrone/cheshire#77 (and affects virtually every other clojure serialization library I've ever used) so I won't elaborate further on the problem statement.

I'm thinking a solution would be another option to the pprint function, which would be a function that accepts a value to be pretty-printed and either returns {:tag __ :value __} or nil, and it would be checked before checking the global protocol (and perhaps before checking built-in functionality as well, though that would probably be a performance concern and I don't know of any use case for it).

@gfredericks
Copy link
Author

I will probably be trying this out myself for a library I'm writing, so I'll point to some code once I have it.

@greglook
Copy link
Owner

greglook commented Oct 4, 2015

Yeah, I've run into this too. I think that Fressian's model might be better for this - you explicitly specify a map of write handlers which are used to serialize, and on the other side you provide a map of read handlers from tags to reader functions.

@gfredericks
Copy link
Author

ah right, so a map whose keys are classes?

@gfredericks
Copy link
Author

how should that interact with the builtin functionality? e.g. what happens if I put clojure.lang.PersistentVector in the map?

@greglook
Copy link
Owner

greglook commented Oct 4, 2015

I think you'd want the explicit handlers to override builtin serialization. Fressian also has a nice lookup-by-inheritance feature so you can use superclasses or interfaces to catch all the descendant types.

@gfredericks
Copy link
Author

okay this sounds cool. incidentally if I end up doing this it will be for https://github.com/gfredericks/webscale

@gfredericks
Copy link
Author

Alright, I think I got it working here.

Some design choices I had to make:

  • name/format for the additional option: :class-lookup is a map from classes to (fn [value] {:tag ... :form ...})
  • where to put the class/interface lookup algorithm: a new namespace puget.class-lookup
  • how to cache results so we don't walk the inheritance hierarchy all the time: add a memoized function to *options* in the with-options macro
  • how to incorporate it into the format-doc multimethod: check the class-lookup before the protocol, and dispatch to a modified version of the ::tagged-literal impl; this entails looking up the impl twice, but I don't think that's much different from what the protocol codepath is doing anyhow

Let me know how this sounds and I can add docs and make a PR.

@gfredericks
Copy link
Author

(edited previous comment to point to a slightly different commit)

@gfredericks
Copy link
Author

oh and tests. also I would add tests.

@greglook
Copy link
Owner

Released 0.9.0 with support for custom print handlers.

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

2 participants