Fork me on GitHub
#cljs-dev
<
2016-01-08
>
maria00:01:55

Tried current master on my personal projects and with regards to js module support and all looks good so far :thumbsup:

richiardiandrea03:01:27

Guys, is the following normal (and why?):

cljs.user=> (js-obj :foo :bar)
#js {::foo :bar} <- two :

richiardiandrea03:01:28

I also found weird that:

cljs.user=> (= {:foo :bar} (js->clj (js-obj :foo :bar)))
false

richiardiandrea03:01:49

with:

my.ns=> (js->clj (js-obj :foo :bar))
{":foo" :bar}

richiardiandrea03:01:40

I can open an issue and have a look at it in case

dnolen04:01:00

None of those things are issues

dnolen04:01:45

@maria thanks for the confirm!

richiardiandrea16:01:33

@dnolen can you expand just a bit? Maybe I am missing some js fu here, but what is a ::foo in a js object? And shouldn't js->clj and js-obj mirror each other? I know you are busy but one hint would be enough so that I can google it

dnolen16:01:27

@richiardiandrea: nothing around js->clj or clj->js is very high priority

dnolen16:01:35

and no there is no round trip expectation at all

dnolen16:01:00

clj->js is inherently lossy

dnolen16:01:24

an there is no relationship between js-obj and the conversion helpers

anmonteiro21:01:08

@dnolen: why is it that @richiardiandrea 's example above works that way? I'm referring to (js-obj :foo :bar) returning #js {::foo :bar}

anmonteiro21:01:25

I mean specifically the 2 colons

dnolen21:01:32

(js-obj :foo :bar) is non-sensical

dnolen21:01:49

it is not a valid call to js-obj

anmonteiro21:01:11

(js-obj "foo" :bar) works

dnolen21:01:16

the keys must be strings

anmonteiro21:01:30

I had forgotten about that

dnolen21:01:40

#js {:foo :bar}

dnolen21:01:53

is purely for aesthetics and saving a keystroke

dnolen21:01:15

it is equivalent to #js {“foo” :bar}

anmonteiro21:01:52

@dnolen: had no idea about this stuff, caused me a few headaches today because I forgot to use strings in js-obj. that clears things up

dnolen21:01:29

there no such thing as JS object w/ non-string keys

dnolen21:01:33

ClojureScript can’t fix that

dnolen21:01:45

and we are not going to bother with any coercion on your behalf

anmonteiro21:01:05

@dnolen: of course, that makes total sense; I somehow was expecting that coercion

dnolen21:01:14

yeah no coercions

dnolen21:01:51

the reader literal is purely a compile time thing (well read-time thing to be more precise) there’s nothing happening at runtime

mfikes22:01:23

@dnolen: I failed to notice something yesterday when testing Natal/Ambly with master. While things work properly, it evidently copies over more than it used to (initial hunch is a cache invalidation issue). I haven’t dug into it yet, but sharing in case others start reporting similar. Here is a gist at least showing it: https://gist.github.com/mfikes/0184826e6f85a6b7128f

dnolen22:01:52

@mfikes it doesn’t actually copy any more than it used to

dnolen22:01:58

we just report that under :verbose now

mfikes22:01:13

Ahh, whew!

dnolen22:01:22

it’s actually important given the enhanced support for doing the right thing when dependencies change

dnolen22:01:41

so if somebody finds a bug it should be easier to see where things went wrong

dnolen22:01:49

users should have to blow away their builds a lot less now