Fork me on GitHub

@richiardiandrea I believe current behavior is intentional. there is some old discussion about js->clj in this thread: including: > clj->js and js->clj already crossed into territory that probably should have been left outside of ClojureScript proper.


Personally I would also prefer smoother interop, like a better js->clj. I’d also really like a built-in way to read a key from a JS object, + destructuring, rather than having to require a namespace and call a function, as we do with goog.object/get now that aget is [officially frowned upon]( but I think the ship has sailed on this stuff.


@mhuebert I already spent some brain cycles on that:


@darwin that’s nice work. I wish something like it was built-in.


definitely not planning on doing anything in this area anytime soon - just too low priority


also not that serious of a feedback point from users


also it would be too difficult to agree on exact behaviour, it is pretty complex stuff with many possible edge cases


yes just not worth it


js->clj issues demonstrates that quite well


yes js->clj is particularly hairy


I’m not opposed to a plan btw


I’m just not going spend anymore of my own brain cycles on this


but even for something like destructuring, where at first glance reading a key could always map to goog.object/get, is there any way to get around the fact that we have to explicitly choose between literal string access vs. access via symbols which are subject to advanced compilation?


Fundamentally structs and maps are different uses. JS idiom is lazy about using objects as maps, which causes this pain. That's going to have to change, as the JS community itself is learning.


Witness map API


However there are some interesting looking things in goog.reflect that may allow more dynamism to survive advanced compilation


And there are the @struct and @dict annotations to help you keep symbol vs string access straight


@U09R86PA4 do you use @struct and @dict annotations in cljs code for this purpose? do you know of good examples? I have never touched them myself


in fact I am not even familiar with the terminology 🙂


>When you annotate a constructor C with @struct, the compiler checks that you only access the properties of C objects using dot notation.


>When you annotate a constructor C with @dict, the compiler checks that you only access the properties of C objects using brackets.


(crossposting from #clojure, 'cuz Alex punted me to here. 🙂 ) Moving to the new Clojure beta caused cljsbuild to fail with:

Sep 19, 2017 1:46:59 PM println
SEVERE: /home/deg/Documents/git/projects/trilystro/target/cljsbuild-compiler-1/cljs/core.js:3579: ERROR - Parse error. primary expression expected
case ##Inf:
This is in the function cljs.core/hash (edited)


@deg I suspect you need at least tools.reader-1.1.0


@mhuebert no - stuff like that is the reason this area hasn’t made significant progress in years


@mfikes - Thanks, I'll take a look at tools.reader. I don't explicitly include any version of it currently. Not clear which dep is using it, but I'll take a look.


Hmm, looks like ClojureScript 1.9.908 depends on tools.reader 1.0.5. Does that mean that this is affecting all current ClojureScript projects?


You were right, of course. Added an explicit dep on tools.reader and excluded it from clojurescript : now my build works. Thanks.


@mhuebert I suppose you could experiment with something like

(extend-type object
    ([o k] (goog.object/get o (name k)))
    ([o k not-found] (goog.object/get o (name k) not-found))))
just to learn where corner cases exist. You can try
(let [{:keys [:a :b]} #js {:a 1 :b 2}] [a b])
I'd bet there are an interested set of good and bad consequences of destructuring JavaScript objects to be learned.


@mfikes I’ve experimented with some things like that, here is an implementation that uses deftype to create a wrapper which allows for nested lookups:


the awkwardness encountered was that i wanted nested lookups, which means recursively wrapping any objects encountered,


but then you have to remember to @unwrap them

Alex Miller (Clojure team)13:09:41

@dnolen when will there be a cljs version that addresses this tools.reader disconnect?


@mfikes extending object like you’ve done avoids this but with global effects, which i thought might be problematic


Right. Only one bit of code can do that 😞


And unknown consequences perhaps


@mhuebert thanks for the link, but mine was more of possible bug seems that goog/typeOf has better behavior regarding detecting the type I of a JS object (the typeof operator in JS returns object for null, aargh) but it seems changing that function with a simple fix like that could break a lot of things


yeah, it is very different. js->clj does not attempt to work for anything with a custom constructor, only Object. switching to goog/typeOf would make js->clj operate on all sorts of javascript things beyond plain objects, a big behaviour change.


@alexmiller I guess we can cut a release just for it - but probably would be Friday

Alex Miller (Clojure team)15:09:35

that’s fine, just trying to figure out the limbo period

Alex Miller (Clojure team)15:09:55

whether it’s days/weeks


I haven’t had a chance to try it but it looks fine to me


yeah I’ll do this on Friday, I didn’t think much interesting had happened on master - but actually that’s not true


@dnolen putting CLJS-2339 on your radar


@mfikes today I sat to improve the canary, newly it renders task\job status matrix on homepage: and I did setup a bot which should run a drill job once a day, babot github user will be responsible for those automated job runs: