This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-19
Channels
- # aws (2)
- # beginners (135)
- # boot (20)
- # chestnut (7)
- # cider (18)
- # clara (5)
- # cljs-dev (50)
- # cljsrn (30)
- # clojure (252)
- # clojure-italy (9)
- # clojure-losangeles (5)
- # clojure-russia (8)
- # clojure-spec (33)
- # clojure-uk (5)
- # clojurescript (32)
- # clr (4)
- # cursive (5)
- # data-science (1)
- # datascript (1)
- # datomic (40)
- # emacs (1)
- # fulcro (18)
- # graphql (11)
- # hoplon (3)
- # lein-figwheel (2)
- # lumo (47)
- # off-topic (2)
- # om-next (3)
- # onyx (10)
- # pedestal (22)
- # protorepl (6)
- # re-frame (7)
- # reagent (38)
- # ring (1)
- # ring-swagger (5)
- # rum (3)
- # spacemacs (19)
- # specter (5)
- # vim (13)
- # yada (16)
@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.
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.
@mhuebert I already spent some brain cycles on that: https://github.com/binaryage/cljs-oops
definitely not planning on doing anything in this area anytime soon - just too low priority
also it would be too difficult to agree on exact behaviour, it is pretty complex stuff with many possible edge cases
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.
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
>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 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)Justification for the claim above: This unit test: https://github.com/clojure/tools.reader/commit/5c48431d02aaf7fece045d96b65e9f04da869450#diff-7d6bed5c1122a5cd9e974af26697933dR64
@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
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.@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
the awkwardness encountered was that i wanted nested lookups, which means recursively wrapping any objects encountered,
@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
@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
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
that’s fine, just trying to figure out the limbo period
whether it’s days/weeks
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: 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