Open Frozenlock opened 9 months ago
Looks like there's already some base64 utilities in nippy
:
(c/defpathtype [0x71
clojure.lang.PersistentHashMap
clojure.lang.PersistentArrayMap
clojure.lang.PersistentTreeMap]
(fn map-encoder [m]
(nippy/freeze-to-string m))
(fn map-decoder [s]
(nippy/thaw-from-string s)))
It's a good idea. Since nippy/freeze-to-string
base64 encodes the value it should be safe. It won't play nicely with the seeking functions (unpredictable ordering), but it shouldn't break anything and there really isn't an obvious total ordering between maps that anyone would be expecting anyway.
We should probably add support for clojure.lang.PersistentHashSet
& clojure.lang.PersistentTreeSet
under that hex-code as well, since the nippy encoder manages it's own type tagging. (You should be able to supply the nippy functions directly to defpathtype
without wrapping them in an additional fn
)
If you want to make a PR I'd be happy to merge it.
You should be able to supply the nippy functions directly to defpathtype without wrapping them in an additional fn
Ah, yes! Vestiges of the previous version :wink:
Turns out it's more complex than what I initially thought. Because those maps act as keys:
(= (sorted-map :a 1) {:a 1})
;=> true
I think I was able to solve all those issues with a surprisingly small amount of code.
There is one downside however... it requires an additional library.
In light of all of this, do you still think it's a good idea to try to incorporate this into Codax? Also, do you have a recommendation as to which hex code should be used? (How did you choose the other ones?)
I appreciate you being so thorough. After giving it some thought on my end, I think by refactoring the pathwise treatment of vectors, it is possible to allow for map and set path keys pretty easily. The set-map-keys branch has a working example, but I am not sure I've fully considered all the implications. Please have a look when you can.
As for the hex code, I don't think I had any solid methodology for selecting hex codes. Really should have reserved some of them for extensions like this since it could, in theory, interfere with other existing custom types.
I was wondering how you could sort heterogeneous data, but it looks like you're encoding it before the sort, which means you're always sorting strings. :+1:
The only failing tests I have with your version is related to clojure.lang.PersistentTreeSet
and clojure.lang.PersistentTreeMap
(sorted-map and sorted-set) as they don't have a path encoder.
But thinking more about it, I really dislike the silent conversion to their unsorted counterpart. It should probably be left to the user to manually do the conversion, if needed.
Really should have reserved some of them for extensions like this since it could, in theory, interfere with other existing custom types.
Should you take the opportunity to reserve a few hex codes? We can't do anything for users of previous versions, but at least users of version 1.4.X and upward could avoid using reserved codes.
Clojurians are used to be able to use pretty much anything as keys, including maps.
Codax is almost there, but lacks support for maps.
I came up with a simple encoder/decoder that leverages Nippy:
Nippy also automatically handles keys ordering:
Could something like this be added to Codax? Could it leverage other types defined for pathwise?