Fork me on GitHub
#cljs-dev
<
2017-09-19
>
mhuebert12:09:02

@richiardiandrea I believe current behavior is intentional. there is some old discussion about js->clj in this thread: https://groups.google.com/d/msg/clojurescript/vtBqlc6OfRI/7h9OT4zxFmcJ including: > clj->js and js->clj already crossed into territory that probably should have been left outside of ClojureScript proper.

mhuebert12:09:02

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](https://github.com/cljs/api/issues/128). but I think the ship has sailed on this stuff.

darwin12:09:54

@mhuebert I already spent some brain cycles on that: https://github.com/binaryage/cljs-oops

mhuebert12:09:03

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

dnolen12:09:50

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

dnolen12:09:07

also not that serious of a feedback point from users

darwin12:09:54

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

dnolen12:09:56

yes just not worth it

dnolen12:09:05

js->clj issues demonstrates that quite well

mhuebert12:09:48

yes js->clj is particularly hairy

dnolen12:09:51

I’m not opposed to a plan btw

dnolen12:09:04

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

mhuebert12:09:39

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?

favila13:09:56

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.

favila13:09:55

Witness map API

favila13:09:23

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

favila13:09:34

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

mhuebert14:09:57

@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

mhuebert14:09:47

in fact I am not even familiar with the terminology 🙂

favila14:09:36

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

favila14:09:44

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

deg12:09:31

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

Sep 19, 2017 1:46:59 PM com.google.javascript.jscomp.LoggerErrorManager 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)

mfikes12:09:02

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

dnolen13:09:58

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

deg13:09:58

@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.

deg13:09:02

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?

deg13:09:25

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

mfikes13:09:26

@mhuebert I suppose you could experiment with something like

(extend-type object
  ILookup
  (-lookup
    ([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.

mhuebert13:09:21

@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: https://github.com/mhuebert/maria/blob/master/maria-editor/src/maria/util.cljs#L41

mhuebert13:09:26

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

mhuebert13:09:36

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?

mhuebert13:09:47

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

mfikes13:09:08

Right. Only one bit of code can do that 😞

mfikes13:09:20

And unknown consequences perhaps

richiardiandrea14:09:03

@mhuebert thanks for the link, but mine was more of possible bug report...it 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

mhuebert15:09:46

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.

dnolen15:09:15

@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

dnolen15:09:25

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

dnolen15:09:53

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

anmonteiro15:09:34

@dnolen putting CLJS-2339 on your radar

darwin21:09:52

@mfikes today I sat to improve the canary, newly it renders task\job status matrix on homepage: https://github.com/cljs-oss/canary 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: https://github.com/cljs-oss/canary/commits/jobs