make js->clj work with purnam, or with extending collection protocols in general?
Feng Hou
Chris Zhang's cljs lib https://github.com/zcaudate/purnam extends native object and array (goog closure) with collection protocols. However, it appears js->clj does not play well with them, patricianly coll? clause match first and empty does structure preserving copy (ie. native object/array are returned as the same native objects).
Here is a simple test
(deftest js->clj-with-purnam
(is (= {} (js->clj (obj))))
(is (= [] (js->clj (arr))))
(is (= [{}] (js->clj (arr {}))))
(is (= {"a" [1 2 3] "b" {"c" nil}} (js->clj (obj "a" [1 2 3] "b" {"c" (seq ())}))))
(is (= {"a" 1, "b" 2} (js->clj (js* "{\"a\":1,\"b\":2}"))))
(is (= {"a" nil} (js->clj (js* "{\"a\":null}"))))
(is (= {} (js->clj (js* "{}"))))
(is (= {"a" true, "b" false} (js->clj (js* "{\"a\":true,\"b\":false}"))))
(is (= {:a 1, :b 2} (js->clj (js* "{\"a\":1,\"b\":2}") :keywordize-keys true)))
(is (= [[{:a 1, :b 2} {:a 1, :b 2}]]
(js->clj (js* "[[{\"a\":1,\"b\":2}, {\"a\":1,\"b\":2}]]") :keywordize-keys true)))
(is (= [[{:a 1, :b 2} {:a 1, :b 2}]]
(js->clj [[{:a 1, :b 2} {:a 1, :b 2}]])))
(is (= (js->clj nil) nil)))
Test Report with clojurescript-0.0-2080. Note that even the later 3 assertions not using purnam obj/arr fns are also failing.
FAIL in (js->clj-with-purnam) (:)
expected: (= [] (js->clj (arr)))
actual: (not (= [] #<Array []>))
FAIL in (js->clj-with-purnam) (:)
expected: (= [{}] (js->clj (arr {})))
actual: (not (= [{}] #<Array [#<[object Object]>]>))
FAIL in (js->clj-with-purnam) (:)
expected: (= {"a" [1 2 3], "b" {"c" nil}} (js->clj (obj "a" [1 2 3] "b" {"c" (seq ())})))
actual: (not (= {"a" [1 2 3], "b" {"c" nil}} #<[object Object]>))
FAIL in (js->clj-with-purnam) (:)
expected: (= {"a" nil} (js->clj (js* "{\"a\":null}")))
actual: (not (= {"a" nil} #<[object Object]>))
FAIL in (js->clj-with-purnam) (:)
expected: (= {"a" true, "b" false} (js->clj (js* "{\"a\":true,\"b\":false}")))
actual: (not (= {"a" true, "b" false} #<[object Object]>))
FAIL in (js->clj-with-purnam) (:)
expected: (= [[{:a 1, :b 2} {:a 1, :b 2}]] (js->clj (js* "[[{\"a\":1,\"b\":2}, {\"a\":1,\"b\":2}]]") :keywordize-keys true))
actual: (not (= [[{:a 1, :b 2} {:a 1, :b 2}]] #<Array [#<Array [#<[object Object]>, #<[object Object]>]>]>))
It seems to me that js->clj cond clauses simply assumed a flat disjoin protocol/type hierarchy (or it's by design in this linear order, seq?, coll? first, then array?, s/Object?). I was able to get the same set tests pass by reordering them here
https://github.com/fengh/clojurescript/commit/aedb0bb
Is is a sensible change?
Thanks,
Feng
Feng Hou
Sorry for misspelling, s/patricianly/particularly/
David Nolen
--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
David Nolen
Gary Trakhman
David Nolen
Gary Trakhman
David Nolen
Feng Hou
Thanks for sharing your thoughts. Thinking about more on this topic (data structure interop between js and cljs world in general), I'm leaning towards following practical approach at this moment.
1. Js natives vs. cljs collections are fundamentally different, ie. mutable vs persistent structurally , imperative vs. functional operationally. Anything trying to unify these two worlds would be either suboptimal (COW), or broken (hiding js objects/arrays behind cljs collection protocols).
2. Js natives being mutable and imperative are useful properties. What we need in cljs world is set of operators that keep these properties *explicit*, at the same time syntactically *concise*. I can see purnam lib already started an experiment with monadic operators.
3. David's mori lib provides a good way for Js to use cljs persistent collections, however, values created in different worlds can't be shared in mori advanced build. mori simple build does provide interoperability between js and cljs world, but not sure it is intent for production use (size is not a concern since gzip takes care it well).
Thanks,
Feng