This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-21
Channels
- # 100-days-of-code (1)
- # announcements (2)
- # beginners (164)
- # cider (23)
- # cljs-dev (30)
- # cljsjs (11)
- # cljsrn (7)
- # clojure (116)
- # clojure-boston (1)
- # clojure-dev (20)
- # clojure-finland (2)
- # clojure-italy (4)
- # clojure-nl (1)
- # clojure-uk (10)
- # clojurescript (39)
- # core-async (19)
- # cursive (43)
- # data-science (2)
- # datomic (24)
- # emacs (10)
- # figwheel-main (20)
- # fulcro (63)
- # hoplon (7)
- # hyperfiddle (7)
- # instaparse (3)
- # kaocha (1)
- # nrepl (3)
- # off-topic (170)
- # onyx (13)
- # other-languages (3)
- # parinfer (13)
- # re-frame (39)
- # reagent (5)
- # reitit (22)
- # ring-swagger (4)
- # shadow-cljs (284)
- # spacemacs (2)
- # sql (27)
- # testing (28)
- # unrepl (2)
@alexmiller re: https://dev.clojure.org/jira/browse/CLJ-1326, the selected method in the example was not really the point, if you do any interop over literal collections you'll get the same behavior
for example interop for the java.util.Collection
methods which the clojure collections are documented to implement (https://clojure.org/reference/data_structures)
Just wondering, about the naming for async-require
, since it's basically require+locking, wouldn't another name be more appropriate?
async-foo tends to suggest something is done asynchronously, I'd argue sync-require
would be more appropriate actually, but that's just me
seems like maps don't implement j.u.C
, possibly an oversight but that goes against the docs, I'll make a ticket about it
Java collections do not include maps
so that’s normal
Map is a separate hierarchy
>In addition, the collections: >Implement the non-optional (read-only) portion of java.util.Collection
then yes, I’d say that’s incomplete
I would add “or java.util.Map”
I've reworded the ticket to suggest the docs might be incomplete instead of the impl being incorrect
docs updated, ticket closed