i tried

(extend-type java.nio.file.Path
    clojure.lang.IPersistentCollection
    (cons [^java.nio.file.Path p ^String more]
      (.resolve p more)))

Execution error (IllegalArgumentException) at ...
interface clojure.lang.IPersistentCollection is not a protocol

I think you’re right. Maybe you could use proxy or reify to create a custom imolementation of Path, but I’m not really sure. But - if we rewind a bit - why do you want to overload conj with this particular operation? This example seems like a perfect use case for a clearly named utility function. I would be surprised to see someone bolt this quite domain specific string-like thing to conj or other collection operations in real life code.

i just felt conj would make (some) sense, because it already has the iteration built into it and i would rather use existing core functions then introduce new ones, which feel like parochialism.

i did write these utility functions at the end:

(defn- join1 [^Path p segment]
  (.resolve p segment))

(defn join [^Path p & segments]
  (reduce join1 p segments))

join sounds like it would turn a and /b into a//b or a/b. resolve makes it sound more like it turns it into /b. Though in Python both os.path.join and pathlib.Path.joinpath work as the latter, but it's not immediately intuitive from the name, and the second function doesn't document the behavior.

would my.fs.utils/conj make more sense?

it's only a protocol in clojurescript like you said https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L600

IMO conj sounds like what I described join sounds like.

Heh, C++ didn't even add a method for it - it's just overloading the / operator (Python also does that, but there's also a method).

C# calls it Combine, I think it's also more clear and intuitive than join/`conj`/"concat" (what C++ calls it in the docs)/`/`.

BTW if you don't need that behavior with absolute segments, any name would do. And you might already be able to use io/file for that (no clue about other protocols - don't have them):

(-> "file:///a/b" java.net.URI. java.nio.file.Path/of
    (io/file "c" "d" "e")
    .toPath)
=> #object[sun.nio.fs.UnixPath 0x51818c79 "/a/b/c/d/e"]

yeah, the problem with mixing io/file into the picture is that it's not aware of the protocol/`java.nio.file.FileSystem` concept, which is why we are transitioning to using Paths

making conj work would imply that into would work too, since into uses conj as its reduction function by default, so (into p ["asd" "qwe/zxc"]) should work too. combine doesn't suggest ordering, but something more intricate.

When you use primitive type hints for a function, the compiler tries to find the matching interface in IFn. In this case, it finds this:

static public interface OLO{Object invokePrim(Object arg0, long arg1);}

And the fix here would be to remove type hints from the arguments. Or at least from the second argument.

Thanks for the answer! I think I'll remove the type hint in the argument and move it in the body of the function

Did you read that in the source code? Can you please point me to it?

Why do you need type hints there at all? Except for the return value. This is where the matching interface is determined: https://github.com/clojure/clojure/blob/4090f405466ea90bbaf3addbe41f0a6acb164dbb/src/jvm/clojure/lang/Compiler.java#L3862 This is the matching interface itself: https://github.com/clojure/clojure/blob/43873e477dff33e5c53323bf8ceddc014b870a40/src/jvm/clojure/lang/IFn.java#L109

Thank you! I stripped down the example so it's not clear, but I need the type hint in the argument to be able to call a java method that expects a primitive long and I don't want to wrap it into a Long which is not necessary

I think this is a bug. Matching against a primitive interface shouldn't prevent type hints from propagating. Does this deserve an AskClojure thread, @U064X3EF3?

Sure

I can create the thread on AskClojure and post the link here if you want (and didn't already)

Would be great if you did!

Done: https://ask.clojure.org/index.php/13501/primitive-type-hints-arguments-turns-the-return-value-object, sorry for the delay

> * Any idea why i'm ending up with the same values for all elements ? most likely because array-of-structs->column returns a new object. So any manipulations with it will not be reflected in vertices-array

Ok that makes sense. I'll try something else

Ok it's not because there is a copy but because I didn't use doseq correctly, it wil iterate i * j times and not i times binding values for idx and [x y z] (if that makes sense)

https://clojure.org/guides/spec#_entity_maps :req vs :opt

I mean programatically

like I have something like this:

(s/def ::test (s/keys :opt-un [::foo] :req-un [::bar]))

and I need a way to programmatically convert that to a definition of:

(s/keys :opt-un [::foo ::bar])

Perhaps if you know under which condition you need the different formats, you could test for that condition and use the correct spec? Or is that not what you are looking for?

I have a definition where certain keys are required, and in other use-cases all of the keys are optional. I don’t want to write the spec down again, to avoid mistakes.

You can write a macro that does that - you'd have two separate specs and you'd choose between them at run time. Maybe you can use spec-tools for that, not sure. But if you need programmatic spec transformation more than once, I'd choose a different tool, e.g. malli.

I’ve came up with this so far:

(defmacro all-keys-optional [spec]
  (let [{:keys [req req-un opt opt-un]} (apply hash-map (drop 1 (s/form spec)))
        optional {:opt (vec (concat req opt))
                  :opt-un (vec (concat req-un opt-un))}
        spec-def (into {} (filter (comp not-empty second) optional))]
    spec-def
    #_(s/keys ~@spec-def)))

if it's clj (not cljs) you can juse use eval and skip the macro, depends how much you have to do this

(def keys [::foo ::bar ::baz]) (eval `(s/def ::full (s/keys :req ~keys)))

I guess you could also make a macro that would parse the s/form of the original spec and write the new one for opts

I have hard time applying the map as keyword args to s/keys

You don't need a map in the first place. But you can use (apply concat ...).

that is true

(defn all-keys-optional [spec]
  (let [{:keys [req req-un opt opt-un]} (apply hash-map (drop 1 (s/form spec)))
        optional {:opt (vec (concat req opt))
                  :opt-un (vec (concat req-un opt-un))}
        spec-def (apply concat (filter (comp not-empty second) optional))]
    (eval `(s/keys ~@spec-def))))

so this should be working, right?

gosh, it was working, I had another problem 😄

thank you!

s/keys also has the :gen argument, if you care about that.

good point!

thank you very much!