reify

I’d like to do it dynamically, i.e. data driven. Let’s say I’m given the protocol definition var, a method symbol, and an fn, and I’d like to return an instance of the protocol that calls f. That’s easy to do when :extend-via-metadata is true. Is it possible to do when its false

I mean with eval yes, but otherwise I'd say it'd require messing with internals if it's possible at all.

presumption that the protocol only has one arity?

@U050ECB92 sure, if that makes it easier

you can automatically generate a proxy that delegates: (defn make-proxy [f] (reify (sig [this ...args] (f ...args))))

statically make one uber-proxy like above, or dynamically using eval (probably memoized by protofn)

If I don’t know the signature of the protocol ahead of time, how do I build that proxy [edit] without eval?

I guess I can call reify* directly

you can examine the arglists on the protofn var meta

you're not going to get away from calling eval if you can be passed an arbitrary protocol impl that you need to make

I just need an existing function. I don’t need eval when :extend-via-metadata is true, so I find it plausible I can do it without. It looks like calling reify* directly might work, will investigate more

that reasoning doesn't follow

when extend-via-metadata=t, it doesn't require new classes (just maps with metadata)

when false, you'll need at least one new class that impls the protocol

new class => needs to go through the compiler

This seems to work (I guess it's an accidental behavior, though):

(defprotocol P (m [this]))
(extend (class conj) P {:m (fn [_] "conj")})

(m conj) ;=> "conj"

for creating a Cluster object you can create it like :

(def builder (Cluster/build))
...
...
(def cluster (.create builder))

(ns ...
 (:import [org.apache.tinkerpop.gremlin.process.traversal AnonymousTraversalSource ...]
          ...))

(def g (.withRemote (AnonymousTraversalSource/traversal) (DriverRemoteConnection/using cluster))) 

does it make sense?

Please don’t crosspost in multiple channels and if you do so then at least link your postings

@U0739PUFQ thank you! this works!

I am surprised jar is looking at file contents at all

actually, I bet I know what it is

the module-info.class in the jar is what has that major.minor version and is what is causing jar to barf, not the stuff under versions

which is why it is a java.lang.module.InvalidModuleDescriptorException

a very wild guess

that sounds like a decent guess. Does that mean that jar cannot handle multi-release jars which contain class files for versions greater than the jdk being used? Seems like a weird thing and nothing seems obviously wrong here

yes

cannot handle multi-release jars which contain class files for versions greater than the jdk being used

Dang. Is that true? Documented anywhere? Seems wild that “java” can correctly ignore the Java 17 files there with the multi release jar but “jar” cannot

as far as I can tell, not documented anywhere - but I treat that as "presume doesn't work". I'm actually amazed the older JRE doesn't yell at you for having the newer class files in there

maybe it's a java 17 and newer thing...

But Java 11 is aware of the multi release feature. Seems crazy it cannot ignore classfiles in a version it would not select for