ClojureScript

add clj->js

Details

  • Type: Enhancement Enhancement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Completed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

For complex keys in maps pr-str should be sufficient and sets could just become JS arrays.

Activity

Hide
Max Penet added a comment - - edited

Here is a first version.
The tests could be improved, let met know if that is necessary (almost 3am for me, I could work on that tomorrow evening).

https://github.com/mpenet/clojurescript/commit/d10b08fa147374118e98e98fdffd9c61f95f9747.patch

It would also be helpful if someone could run the tests against JSCore for me. Thanks!

edit: I changed the patch to do whitelisting instead of blacklisting of types in key>js, it should be safer and provide sane default for unknown js objects.

Show
Max Penet added a comment - - edited Here is a first version. The tests could be improved, let met know if that is necessary (almost 3am for me, I could work on that tomorrow evening). https://github.com/mpenet/clojurescript/commit/d10b08fa147374118e98e98fdffd9c61f95f9747.patch It would also be helpful if someone could run the tests against JSCore for me. Thanks! edit: I changed the patch to do whitelisting instead of blacklisting of types in key>js, it should be safer and provide sane default for unknown js objects.
Hide
David Nolen added a comment -

Thanks much. I will check it out tomorrow morning.

Show
David Nolen added a comment - Thanks much. I will check it out tomorrow morning.
Hide
David Nolen added a comment -

This patch looks good, can we get a proper patch attached to this ticket? Thanks!

Show
David Nolen added a comment - This patch looks good, can we get a proper patch attached to this ticket? Thanks!
Hide
Nicola Mometto added a comment - - edited

what's the point of doing eg

(extend-protocol proto
  default
  (proto-fn [x]
    (cond x
      (string? x) do-a
      (vector? x) do-b
      :else do-c)))

rather than using extend-protocol on the specific types

(extend-protocol proto
  string
  (proto-fn [x] do-a)
  IPersistentVector
  (proto-fn [x] do-b)
  default
  (proto-fn [x] do-c)))
Show
Nicola Mometto added a comment - - edited what's the point of doing eg
(extend-protocol proto
  default
  (proto-fn [x]
    (cond x
      (string? x) do-a
      (vector? x) do-b
      :else do-c)))
rather than using extend-protocol on the specific types
(extend-protocol proto
  string
  (proto-fn [x] do-a)
  IPersistentVector
  (proto-fn [x] do-b)
  default
  (proto-fn [x] do-c)))
Hide
David Nolen added a comment -

The second approach will require considerably more code as extend-type to IPersistentVector doesn't work in ClojureScript, you have to enumerate all IPersistentVector types. Also enumerating all those types explicitly closes the door for people to override the default behavior if that's desired. I think the patch is sufficient to cover common usage - I'm inclined to let more sophisticated solutions get sorted out in a contrib if people don't find this implementation sufficiently customizable.

Show
David Nolen added a comment - The second approach will require considerably more code as extend-type to IPersistentVector doesn't work in ClojureScript, you have to enumerate all IPersistentVector types. Also enumerating all those types explicitly closes the door for people to override the default behavior if that's desired. I think the patch is sufficient to cover common usage - I'm inclined to let more sophisticated solutions get sorted out in a contrib if people don't find this implementation sufficiently customizable.
Hide
Max Penet added a comment -

I just added the patch file.

Show
Max Penet added a comment - I just added the patch file.
Hide
Wilkes Joiner added a comment -

Do we want symbols and keywords to drop their unicode prefixes?

Show
Wilkes Joiner added a comment - Do we want symbols and keywords to drop their unicode prefixes?
Hide
David Nolen added a comment -

I don't see why they should retain them, I'm leaning towards Keyword & Symbols being proper datatypes - necessary for bootstrapping CLJS.

Show
David Nolen added a comment - I don't see why they should retain them, I'm leaning towards Keyword & Symbols being proper datatypes - necessary for bootstrapping CLJS.
Hide
Wilkes Joiner added a comment -

It triggered my information loss button. Since keywords and symbols are compiled to special strings, would retaining the indicators allow for easier mapping back from a js library into our cljs code?

Show
Wilkes Joiner added a comment - It triggered my information loss button. Since keywords and symbols are compiled to special strings, would retaining the indicators allow for easier mapping back from a js library into our cljs code?
Hide
Max Penet added a comment -

Wilkes, I am not sure it would be a good idea, JSON libraries (cheshire, data.json etc) are a good example of this, you just fallback to the closest format that makes sense with the host/format. Nothing prevents your to create new Types and extend these protocols if you want to retain more information though.

Show
Max Penet added a comment - Wilkes, I am not sure it would be a good idea, JSON libraries (cheshire, data.json etc) are a good example of this, you just fallback to the closest format that makes sense with the host/format. Nothing prevents your to create new Types and extend these protocols if you want to retain more information though.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: