Looks like clojure specifies this on https://clojure.org/reference/protocols > You can implement a protocol on an interface > but opens the door to incidental multiple inheritance of implementation > since a class can inherit from more than one interface, both of which implement the protocol > if one interface is derived from the other, the more derived is used, else which one is used is unspecified. I guess this falls into "Unspecified"

Yes

One clever trick for this case is to check the actual concrete type at runtime and dynamically install a new extension for the concrete type that goes to the one you want

So after the first call you get fast routing

Something like this?

(when (try (Class/forName "org.asciidoctor.jruby.ast.impl.DescriptionListEntryImpl")
           (catch Throwable _ nil))
  (extend-protocol IChildren
    (Class/forName "org.asciidoctor.jruby.ast.impl.DescriptionListEntryImpl")
    (-children [this]
      (conj
        (seq (.getTerms this))
        (.getDescription this)))))

not sure I understand why you're checking if the class exists as the condition

I would expect something that looks at an impl and decides which of the possible extensions to do

I'm talking about a condition inside an extension

I have an example of this in ch 1 of Clojure Applied (really more about protocols on protocols, but it's the same technique)

Oh, hmm. I maybe misunderstood you. I'm checking if the class exists because it's an internal implementation detail of the library I'm using and it might go away.

yeah, you misunderstood - you can do this dynamically without caring about the actual class

(extend-protocol Foo
  SomeInterface
  (some-method [o]
    (if (..some-condition..)
      (do (extend-protocol Foo
            (class o)  ;; whatever impl, don't care, just detect at runtime
            (some-method [o]
              (some-method-impl o))
          (some-method o))  ;; re-invoke but now we've installed a handler
      ...)))

instead of SomeInterface there, this could be Object too - the catch-all default for protocols. basically if you invoke the protocol method on some unknown type, detect that, use whatever tools you need to determine how to handle it, dynamically install a handler for the concrete class, and re-invoke

Ah, I was going to say that it would be slow, but on Object that's not a problem (for me)

it's only slow the first time

after that, the concrete class is installed and you never hit the conditional logic again

It would slow down a particular implementation if the SomeInterface had an actual implementation tied to it, unless you always extend it to something concrete.

again, there are only so many concrete impls - after you've seen each of them once, you'll never hit the conditional logic

at the very first conj, Chris Houser was doing a talk about protocols and someone asked a question like this and Rich suggested this technique from the audience, which is where I learned it. have used it several times.

you do have to be careful of anonymous impls or reify's etc as those are one-off class instances

but generally I've used this when I control enough of the use and domain to assess that

I think https://clojuredocs.org/clojure.core/not is what you want?

Perfect; thank you!

without knowing anything about your problem domain, a jar is fine.

A war is only required if you're deploying to an existing web container (i.e., jetty, tomcat etc...)

As Ring also includes jetty (as a dependency), then a war isn't required.

You can lein ring uberjar, then CMD java -jar abc-standalone.jar in dockerfile

oh then I'll settle with .jar then. Thanks

I don't watch "Java news" closely but I somewhat follow DZone and InfoQ updates which are often about Java ecosystem. I also subscribed to Java/JVM tag on Stackoverflow and there's the Java Specialists slack and related newsletter. Mechnical Sympathy is a also a great mailing lists which is often about JVM internals.

If you want to dig deeper than it might be fun to follow JVM experts - some of my favorite: • Gil Tene • Brian Goetz • Cliff Click • Andrei Pangin • Martin Thompson

Thanks jumar I'll take a look.

You can use standard ring middleware to parse the POST parameters. These will be available in :params or :form-params. See https://ring-clojure.github.io/ring/ring.middleware.params.html (Feel free to continue on #liberator)

Thanks, got it. Will try that now.