(filter (comp not nil? val) ...)

Better to use some? instead of not nil?

But, yes, better to use val than second when dealing with map entries.

@U010Z4Y1J4Q This really feels like a question that is better suited to the #beginners channel where people have opted-in to help with basic questions like this...

Ah, some? ... I didn't remember it. Yes, this would be cleaner: (filter (comp some? val) ...)

@U051MHSEK The OP mentioned it in their question.

I misread it as some and that just shows me what happens if I haven't written Clojure in a while ¯\(ツ)/¯

And another reason why questions like this belong in #beginners rather than #clojure ...

@U010Z4Y1J4Q I've added you (back) to the #beginners channel.

I wonder if #beginners is misnamed.

It’s an attribute of the questioner, not the question.

Happy to discuss potential renaming in #community-development but we try to rename channels only very occasionally (since channel names are often documented out in the wild and it's confusing if someone comes here and those documented channels no longer exist).

Makes sense!

You unquoted twice, you don't want to unquote the entirety of the run-test-sync. Should probably be

(defmacro deftest-sync [name test]
  `(deftest ~name (run-test-sync ~test)))

That still gives (deftest-sync some-test (is (= 1 1))) on macroexpand

Are you sure? I just tried this in the repl:

user=> (defmacro deftest-sync [name test]
  #_=>   `(deftest ~name (run-test-sync ~test)))
#'user/deftest-sync
user=> (macroexpand '(deftest-sync some-test (is (= 1 1))))
(user/deftest some-test (user/run-test-sync (is (= 1 1))))

yeah, I'm sure. Could it be because it's a cljs repl?

I wouldn't know, never worked with cljs

Yeah it's working in the clojure repl but not in the clojurescript repl

😮

bug?

bug in the repl or in cljs itself?

actually it woks now

However, the macro doest seem correct

(deftest my-test (run-test-sync (is (= 1 1)) (is (= 2 1)) ) ) evaluates to #'mytest

But (deftest-sync my-test    (is (= 1 1))    (is (= 2 1))       ) evaluates to (deftest nil nil)

We already use another implementation. Once i'm expanding a existent library, probably not going work on it now. But thanks for the suggestion

you should typically prefer Double/parseDouble over Float/parseFloat

will check out that Double/parseDouble

same answer .. but what is reason to prefer Double ?

Clojure decimals are always doubles - Clojure doesn't support java floats

gotcha .. good to know

single precision floats are pretty bad, really only useful if you want something where you are ok with bad precision and trying to shave heap memory

They don't belong in #clojure but feel free to post them to #news-and-articles (or #off-topic since they aren't Clojure-related, right?)

though I am wondering why (complement zero?) works in the filter as is and (not zero?) needs to be wrapped in an anon. function..

complement returns a function, not returns a value

yep, i guessed it's some of this kind of magic 🙂

@U11BV7MTK (complement zero?) wins, there are fewer brackets and therefore it's more readable and less thinking 'wtf had I written a year?' ago : }. thanks

sometimes I wish things like partial, complement, comp all had shorter names

eg. complement could be ~ or even !

Oh I really like that

(def not-zero?
  (into #{}
        (remove zero?)
        (range Long/MIN_VALUE
               Long/MAX_VALUE)))

@U051SS2EU I wished for the shorter names as well, especially to use in (comp) and settled on (def pa partial)

you shouldn't use = to check for 0, at least one should use ==, and zero? exists for a reason

in the past I've used a dispatch to ensure there was only one code-path for each type, eg. you could have a multimethod or protocol where the implementations would look the same except the type hint

it might be overly precious to use a macro for this, if it's not a repeating pattern you could even use cond

The set of possible input classes is actually open-ended in this case.

I have some reflection code that works but it's ugly 🙂

in that case you could use a protocol or multimethod and extend it to each thing, clojure won't complain about runtime protocol dispatch

It probably relates to this: https://archive.clojure.org/design-wiki/display/design/Function%2Boverloading.html

Where they mention the current solutions are multi-methods, protocols or instance? checks

yeah, since this is open and not statically knowable, protocol or multimethod actually fit here IMHO

No, this has to be self-contained and require no extension by users.

So far

(defn- attempt-close
  "Given an arbitrary object that almost certainly supports a `.close`
  method that takes no arguments and returns `void`, try to find it
  and call it."
  [obj]
  (let [^Class clazz (class obj)
        ^java.lang.reflect.Method close
        (->> (.getMethods clazz)
             (filter (fn [^java.lang.reflect.Method m]
                       (and (= "close" (.getName m))
                            (empty? (.getParameterTypes m))
                            (= "void" (.getName (.getReturnType m))))))
             (first))]
    (when close
      (.invoke close obj (object-array [])))))

That avoids reflection warnings from the compiler and calls the first 0-arity .close method it can find that returns void.

It's so next.jdbc can support Stuart Sierra's Component library without needing it as a dependency in a nice, generic way:

(defn component
  "Takes the same arguments as `->pool` but returns an entity compatible
  with Stuart Sierra's Component: when `com.stuartsierra.component/start`
  is called on it, it builds a connection pooled datasource, and returns
  an entity that can either be invoked as a function with no arguments
  to return that datasource, or can have `com.stuartsierra.component/stop`
  called on it to shutdown the datasource (and return a new startable
  entity)."
  [clazz db-spec]
  (with-meta {}
    {'com.stuartsierra.component/start
     (fn [_]
       (let [pool (->pool clazz db-spec)]
         (with-meta (fn ^DataSource [] pool)
           {'com.stuartsierra.component/stop
            (fn [_]
              (attempt-close pool)
              (component clazz db-spec))})))}))

what about an instance? check that special cases c3p0 (grandfathers it in) and demands all other inputs be http://java.io.Closable ?

(def ds (component/start (next.jdbc.connection/component CPDSClass {:dbtype "..." :dbname "..." ...})))
(next.jdbc/execute! (ds) ["select ..."])
(component/stop ds)

I don't know that you can rely on arbitrary connection pooling libraries implementing .Closable and next.jdbc cannot introduce a direct dependency on a specific one (such as c3p0).

OK

The joys of writing dependency-free libraries that can behave generically... 🙂

Hum... What about letting the user provide the type hint?

There's something about hidden reflection in a library dependency that seems dirty to me.

Making a GraalVM build will require a big deep dive now for example.

Like what if component let you pass in the close function?

Horrible usability.

(although I suppose I could default the close-fn to (fn [^.Closeable ds] (.close ds)) and force poor old c3p0 users to override it... not that HIkariCP doesn't also have its own weirdness)

or default it to (memfn close)which silently reflects I was wrong, it does reflect

I wouldn't be surprised if there are other things that prevented GraalVM binaries to be produced from next.jdbc programs already -- Borkdude is working on JDBC support in Babashka and, so far, has only managed to get PostgreSQL supported -- both MySQL and SQLite seem somewhat incompatible with Graal...

Can you just set warn on reflection false above it and then reenable afterwards?

@U051SS2EU Oh really? Interesting... let me try that...

((memfn close) pool) produces a reflection warning @U051SS2EU

yeah - sorry I did edit above

@U11BV7MTK That sounds... deliciously horrible...

Maybe just keep the warning?

What's the big deal? I mean, if you are doing reflection, why not be explicit about it if the user cares to know.

@U0K064KQV for folks who set reflection warnings on for their whole build, why should they have to suffer my code producing a warning? Folks create GitHub issues about that sort of stuff. No, just no.

@U11BV7MTK That certainly does hide the reflection warning but a) that feels like cheating and b) that's still going to trip anyone who uses Graal, right?

gh issue "this code reflects" response "get rid of reflection by providing this arg / extending this multimethod"

I mean I get it, but I'm not a fan of circumventing the warning either. If I set warn-on-reflection it's because I want to know if reflection is happening anywhere in the code, libraries included

Right, and it's important to me that my library is "clean" in that respect.

Well it seems in line with your intention that you are open to reflection. It’s not a warning it’s intentional

With respect to not be doing reflection? Or not warning about doing it?

Could graal people use this regardless of the warning? The reflection will kill them not the warning

It's probably irrelevant in this case, so it might be the right trade off, but what if I was calling component in a hot loop? I know what doesn't sound realistic, but I'm just trying to explain why I kind of don't like it if my dependencies secretly try to hide important aspects from me.

actually connecting to a db is so much slower than reflecting on a method though

My personal vote would be, leave the warning, but have a mechanism where the user can get rid of it by say providing the close function or a type hint.

If using java.lang.reflect kills Graal then it's a non-starter too... which is moving me closer to @U0K064KQV’s suggesting of optionally passing in the close function at this point

(and defaulting it to the .Closeable version)

that means you get a runtime crash when the hint doesn't match the impl coming in

Actually, you can use java.lang.reflect, but you need to tell Graal which class needs reflecting over

unless you protect it in a conditional branch with an instance? check I guess

So if you document it properly it might be fine as well.

I thought they were hints, because if Clojure compiler doesn't actually find the method on the type it defaulted back to Object?

Though I guess there is the weird case of a connection pooling library that wouldn't have a .close method at all?

@U0K064KQV

(ins)user=> (def hinted #(.close ^.Closeable %))
#'user/hinted
(ins)user=> (defprotocol Distance (close [this]) (far [this]))
Distance
(ins)user=> (hinted (reify Distance (close [this] true)))
Execution error (ClassCastException) at user/hinted (REPL:1).
class user$eval202$reify__203 cannot be cast to class .Closeable (user$eval202$reify__203 is in unnamed module of loader clojure.lang.DynamicClassLoader @50a3d0f6; .Closeable is in module java.base of loader 'bootstrap')

once you hint, the method is specialized on the class, and other methods with the same signature but different class with crash

I discovered this the hard way implementing a setUncaughtExceptionHandler for a kafka stream (that just happened to accept the same types / args as Thread.setUncaughtExceptionHandler without inheriting Thread)

Yeah, that's an interesting usability question @U051SS2EU...

Interesting, didn't know that.

Thinking about this some more, next.jdbc uses clojure.java.data for the connection pooling stuff which is full of explicit Java reflection stuff... So I'm worrying too much about this since ->pool already depends on the java.lang.reflect stuff!

So I've gone back to this

(if (isa? clazz .Closeable)
                (.close ^.Closeable pool)
                (attempt-close pool))

Thank you everyone for your input on this. I guess allowing users to pass in their own close-fn might also be worthwhile just to deal with connection pooling libraries that don't even have a .close function...

there's also this if you don't otherwise need to extract the class

(instance? java.lang.CharSequence "hi")

the rest of clojure is so unbelievably consistent, the difference between isa? and instance? arg order sticks out

Yeah, it caught me out when I tried it half an hour ago -- the way next.jdbc.connection/->pool works is that it already takes a Class so I'm using that to provide the default close-fn before creating the pool instance.

Here's the finished code on next.jdbc master https://github.com/seancorfield/next-jdbc/commit/66fdba4be9a80a85d5fc75df0a2341820b10fa22

extension via metadata to not depend on the component lib. Cool!

It all started as yak shaving due to Jacob O'Bryant's announcement of his Component alternative which inspired me to remove a record from a Component at work and then I started thinking about next.jdbc 🙂

I suggested that or multimethod in the thread above, I don't think he liked the idea