Closed rauhs closed 6 years ago
See more details in #42 justifying this given transit-clj
supports it, and its greater importance now, given the changes in ClojureScript master that emit cljs.core/MapEntry
instances when seqs are formed over hash maps. Additionally #42 shows that the older cljs.core/BlackNode
and cljs.core/RedNode
should be supported as well.
@swannodette Raised a good point in that this ticket could use a little more clarification. In particular, things can get messy if you are open to the idea the sorted map entries may not be terminal, thus raising the question of how exactly they should be encoded.
I took a look at the specs to ascertain what transit-clj
was doing:
Any Clojure hash or sorted map entry me
satisfies both
(instance? clojure.lang.IPersistentVector me)
and
(instance? java.util.List me)
Thus, Clojure unambiguously maps map entry values to the Transit array
semantic type.
What should ClojureScript do? The mapping table for ClojureScript indicates that cljs.core/IVector
is mapped to the array
semantic type when writing.
Any ClojureScrhipt hash or sorted map entry me
satisfies
(satisfies? cljs.core/IVector me)
Thus it seems cut-an-dry that the ClojureScript map entries should be mapped to the array
semantic type upon writing, not because cljs.core/IMapEntry
has any specified mapping in the table, but because cljs.core/IVector
does.
I'm tempted to simplify the above by saying that if a value
v
satisfiesvector?
in either Clojure or ClojureScript, then that value should be mapped to thearray
transit semantic type, but in reality the Clojure and ClojureScript language-level binding specifications are written in terms of Java interfaces and ClojureScript protocols, not in-language predicates likevector?
.
New CLJS type MapEntry should be handled by the writer.