This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-23
Channels
- # beginners (27)
- # boot (8)
- # cider (17)
- # cljs-dev (8)
- # cljsrn (5)
- # clojure (56)
- # clojure-dev (34)
- # clojure-gamedev (4)
- # clojure-italy (32)
- # clojure-nl (22)
- # clojure-poland (3)
- # clojure-russia (17)
- # clojure-spec (31)
- # clojure-uk (48)
- # clojurescript (47)
- # core-async (41)
- # cursive (13)
- # datomic (22)
- # emacs (9)
- # figwheel (7)
- # fulcro (18)
- # graphql (3)
- # hoplon (15)
- # jobs-discuss (38)
- # keechma (1)
- # luminus (10)
- # off-topic (42)
- # onyx (8)
- # overtone (3)
- # protorepl (5)
- # re-frame (42)
- # reagent (6)
- # reitit (3)
- # schema (4)
- # shadow-cljs (39)
- # slack-help (5)
- # spacemacs (8)
- # specter (1)
- # tools-deps (36)
- # uncomplicate (9)
- # vim (34)
is there a technical reason why Clojure doesn’t automatically handle Java varargs, so you could avoid (into-array Object your-thing)
?
Isn't that more because Java doesn't really support varargs, and just translates the function to one that accepts an array under the hood? That's an interop detail that affects every language calling into Java.
I think I wrote a varargs macro sometime that was sugary
(varargs methodName target a b c ^HintTheArray ... x y z)
The analyzer could be compatibly extended to understand this syntax when doing a non-reflective call to a known varargs method:
(.methodName target a b c ^HintTheArray ... x y z)
I think there is 0 chance we are going to do that
so if my interpretation is correct, the problem isn’t really that it’s unclear how it should work, it’s more that noone has actually implemented it, made sure all the corner cases are covered etc?
I think this is one of those things where the goal is obvious but there are a lot of non-obvious and potentially ambiguous cases to be covered
you’re both right probably, but it’s also in that tantalising region of small enough to be understandable and big enough to be interesting 😉
this is certainly an annoying part of Java interop and one that would be nice to improve
will probably also complicate the Reflector method selection code, which already has some pending trauma due to the Java 9 changes
(ns varargs
(:require [clojure.spec.alpha :as s]
[clojure.string :as str]))
(s/def ::method
(s/or :static qualified-symbol?
:instance (s/and simple-symbol? #(str/starts-with? (name %) "."))))
(s/def ::separator
(s/and #{'...} (comp :tag meta)))
(s/def ::varargs-invoke
(s/cat :call ::method
:anything (s/* any?)
:sep ::separator
:varargs (s/* any?)))
(s/fdef varargs :args ::varargs-invoke)
(defmacro varargs [& args]
(let [[call [sep] args] (partition-by #{'...} args)
tag (-> sep meta :tag)]
`(~@call ~(with-meta `(into-array ~tag ~(vec args))
{:tag tag}))))
@cfleming it was something like that. Note that it only takes Class type hints, not #{bytes ints chars longs}
sugar
I'm sure there is a better way to express the last couple lines, but I just crapped that out
it's fundamentally ambiguous, I think. so it requires user input somehow to say whether you're passing one arg or an array of them
I typed that after seeing the first three messages
slack showed me the other dozen after I sent it
which I haven't read yet so I don't know how redundant I was being 🙂