Take a look a Lacinia

https://github.com/walmartlabs/lacinia

Oh. But much more tolerable since it is so rare and already annoying to have to use proxy.

yeah, and the scope for which this will give "false" positives is much smaller

Definitely not the most optimized version

this is mine - also not really optimised. It does handle the case that there can be more than 1 vectors to return, though.

(defn max-vecs
    [coll]
    (let [n (apply max (flatten coll))]
      (filter (partial some #{n}) coll)))

or the code golf version:

(defn max-vecs
    [coll]
    (filter (partial some #{(apply max (flatten coll))}) coll))

https://clojurians.slack.com/archives/C03S1KBA2/p1615554762053600

TIL max-key @U04V15CAJ

Weird naming

indeed

thanks for all the replies guys! I didn't know about max-key either, that one is quite elegant.

Late to the party, this takes the input as requested and delivers the output too (not optimised)

(defn max-vec [v] 
  (let [res (map #(vector (apply max %) %) v)  
        m (into {} res)] (get m (apply max (keys m)))))

How about

(last (sort-by #(apply max %) [[1 5 3] [4 10 35 9] [2 7 19]]))

Safe version (also makes sure the original input vector is not empty, which also fails.

(when-let [coll (not-empty (remove empty? [[1 5 3][4 10 35 9][2 7 19]]))]
  (apply max-key #(apply max %) coll))

You can also fold the empty? check into the predicate

that L prefix means it wants an array of string, which can be implicit if the method takes varargs

you probably need to share your code (or a simplified version), but another issue is that gen-interface doesn't reload like normal clojure code, so your repl might not reflect the current code even if you reloaded the code

Hm, okay. I don’t have my Leiningen REPL set up right, so it doesn’t reload correctly and I always end up exiting it and starting it again when I try testing it like this.

My entire gen-interface is here:

(gen-interface
  :name XSLTTransformer
  :methods [[transform [java.io.File java.io.File] void]
            [transform [javax.xml.transform.Source java.io.File] void]
            [transform [java.io.File] String]
            [transform [javax.xml.transform.Source] String]
            [transform [String] String]
            [updateConfiguration [java.util.Map] void]
            [getConfiguration [] java.util.Map]
            [setConfiguration [java.util.Map] void]])

also gen-interface is a weird corner of the language, I've never needed it, there could be gotchas that I'm unaware of still. what's your use case - you need java code to use your lib via an interface?

or a java lib is written such that it takes an interface as a parameter?

I don't see how any of those methods would end up taking or returning an array

Well, I ended up creating this in a Java-ish way, but basically I have two XSLT transformers that I need to wrap with a consistent API that will be used from Java.

I have a hunch this would be much easier using a gen-class, plus a implementation object that extends a clojure protocol

(in clojure land, each instance of the object would own as member data an implementation of the protocol)

Oh, okay, something weird is happening because I’m trying to delegate. This is probably a stupid approach, but I didn’t have a lot of time to get it done. Basically there are two gen-classes that implement the interface and then there’s a third class that implements the interface and uses its constructor to choose one of the other two classes to delegate to.

Ah, okay, so I’d want a protocol like “Transformable” or something, then define the methods from there?

right, you can still do the delegation with protocols, but protocols play nicer with the rest of clojure I think -the big gotcha here is that protocols don't differentiate methods for dispatch based on type, only name plus arg count

(I don't have proof that gen-interface doesn't have the same issue...)

Interesting, thanks. I’ll have to reread the documentation for protocols - I’ve used them a bit, but I don’t have the experience to necessarily know when/why to use them. I still need to figure out what’s going wrong with my delegation for now, but what you’re suggesting seems like a better direction that’s more Clojure-ish.

the docs say that if you aren't compiling gen-interface is a no-op, are you using a separate aot step?

Yeah, I have the classes set to aot in my project file

I feel a bit irresponsible trying to weigh in here when I haven't used it (and also know it will be weird), but I don't think there are many people who use the function so I hope some answer is better than none

Aha, replacing the gen-interface with a protocol seems to have fixed the immediate issue - I’ll have to go back later and try to rearrange things to take better advantage of the protocol, but this gets me to where I need to be. Thanks!

consider writing a doc on http://clojuredocs.org or a blog post if you figure out how to make gen-interface work- it feels like a dark corner of the language currently

java.lang.AbstractStringBuilder

java.lang.VirtualMachineError, if you need a public constructor.

cool, I wondered if the args to the super contructor can be dynamic and they can be:

(defn foo [m]
  (proxy [java.lang.VirtualMachineError] [(:msg m)]))

(prn (.getMessage (foo {:msg "bar"})))

$ bb -e "(defn dyn-match [pat & clauses] (eval \`(clojure.core.match/match ~pat ~@clauses))) (dyn-match [(+ 1 2 3)] [(+ 1 2 3)] :yo)"
:yo

yeah, that is what I figured. Doable but kind of a bummer that we have to know the patterns ahead of time (or use eval). Would be cool if core.match had a data driven interface.

I think the main reason it's a macro is that the pattern can be compiled to something efficient

Take a look at matchete if you need something more basic and fn-driven: https://github.com/xapix-io/matchete

or maybe even malli

the usage of the patterns is going to be time sensitive, so I would like the benefit of the efficient compilation. If eval works, I would be fine with it as I run the compilation “offline”.

I will check out your other suggestions too and see if one of those might be a better fit.

Also #meander has an interpreter which accepts data instead of compile time patterns (it does both)

With malli:

user=> (m/parse [:catn [:a [:= 1]] [:b :any] [:c [:= 3]]] '[1 2 3])
{:a 1, :b 2, :c 3}

AFAIK s/fdef will be checked against only if the corresponding function have been instrumented: https://clojure.org/guides/spec#_instrumentation

@U2FRKM4TW yeah the function is instrumented

FYI this was answered here https://ask.clojure.org/index.php/10347/spec-instrumentation-does-not-work-with-extend-with-metadata