ClojureScript

Implement printing & equality for the JSValue type

Details

  • Type: Enhancement Enhancement
  • Status: Open Open
  • Priority: Trivial Trivial
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Patch:
    Code and Test

Description

Using the JSValue type in Clojure tests is a little bit cumbersome at
the moment. The following test for example is not passing at the
moment, because equality is not defined on JSValue.

(is (= '(js/React.DOM.div #js {})
'(js/React.DOM.div #js {})))

It would be nice if the JSValue type implements at least equality and
tagged literal printing on the Clojure side as well. The attached
patch implements this functionality.

  1. js-value-print.diff
    25/Dec/13 10:10 AM
    2 kB
    Roman Scherer
  2. js-value-print-only.diff
    25/Dec/13 12:53 PM
    1 kB
    Roman Scherer

Activity

Hide
David Nolen added a comment -

The equality test doesn't match equality semantics in JavaScript. So while this is convenient, this is going to need a really strong argument. I'm inclined to just say no.

Printing for JSValue is OK with me.

Show
David Nolen added a comment - The equality test doesn't match equality semantics in JavaScript. So while this is convenient, this is going to need a really strong argument. I'm inclined to just say no. Printing for JSValue is OK with me.
Hide
Roman Scherer added a comment - - edited

Ok, this solves half of my problem. My strong argument for the
equality test would be "but JSValue lives in Clojure land, and
consumers (analyzer, compiler, tests) of JSValue are better served
with the same equality semantics that Clojure already provides". My
use case for this is over here:

https://github.com/r0man/sablono/blob/js-literal/test/sablono/compiler_test.clj#L18

The sablono compiler generates forms that can contain JSValues. Those
forms I need to check for equality in my tests. Ok, I can define my
own equality operator that walks the forms and replaces JSValue with
something else, but that feels really strange. Any other idea?

Can you make an example why implementing equality this way would be
problematic? I think I didn't get your point.

If you are still against it, I'm happy to provide a patch for the
print functionality. That's the one I really need. Unfortunately this
one I could have provided myself, the equality thing not.

Show
Roman Scherer added a comment - - edited Ok, this solves half of my problem. My strong argument for the equality test would be "but JSValue lives in Clojure land, and consumers (analyzer, compiler, tests) of JSValue are better served with the same equality semantics that Clojure already provides". My use case for this is over here: https://github.com/r0man/sablono/blob/js-literal/test/sablono/compiler_test.clj#L18 The sablono compiler generates forms that can contain JSValues. Those forms I need to check for equality in my tests. Ok, I can define my own equality operator that walks the forms and replaces JSValue with something else, but that feels really strange. Any other idea? Can you make an example why implementing equality this way would be problematic? I think I didn't get your point. If you are still against it, I'm happy to provide a patch for the print functionality. That's the one I really need. Unfortunately this one I could have provided myself, the equality thing not.
Hide
David Nolen added a comment -

Consider if we bootstrapped and JSValue disappeared and we could use the JS Array type directly instead. But arrays are not equal in Clojure(Script) because they are not values.

Show
David Nolen added a comment - Consider if we bootstrapped and JSValue disappeared and we could use the JS Array type directly instead. But arrays are not equal in Clojure(Script) because they are not values.
Hide
Roman Scherer added a comment -

Ok. Thanks for the explanation.

Show
Roman Scherer added a comment - Ok. Thanks for the explanation.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated: