Clojurians Log v2

Hi! Working my way through Java interop and method overload. I have this Java class:

package pets;
import java.util.Arrays;
public class Pets {
    public interface Pet { }
    public static class Dog implements Pet { }
    public static class Cat implements Pet { }
    public static String isA(Pet p) { return "pet"; }
    public static String isA(Dog d) { return "dog"; }
    public static String isA(Cat c) { return "cat"; }
    public static void main(String[] args) {
        System.out.println(isA(new Dog()));
        System.out.println(isA(new Cat()));
        for (Pet x : Arrays.asList(new Dog(), new Cat()))
            System.out.println(isA(x));
    }
}

dog
cat
pet
pet

(import (pets Pets Pets$Dog Pets$Cat))
(println (Pets/isA (Pets$Dog.)))
(println (Pets/isA (Pets$Cat.)))
(doseq [x [(Pets$Dog.) (Pets$Cat.)]]
  (println (Pets/isA x)))

dog
cat
dog
cat

public static String isA(Object x) { return "thing"; }

dog
cat
thing
thing

I think your doseq is equivalent to:

for (Object x : Arrays.asList(new Dog(), new Cat())) System.out.println(isA(x));

and I think (that's two thinks in a row) the clojure compiler only tries to match on interfaces if it can't find a direct match - your isA(Object x) can be called without any more inspectrion of type heirarchies so it goes for that

maybe post this on the Clojure FAQ site - it's an Alex Miller-ish type of question

@henrikheine When you provide isAt(Object x) in the java code then the Clojure compiler will at compile time insert a call to that method. If you leave out isAt(Object x) then at compile time the Clojure compiler cannot find a matching method isAt(Object x) and will insert a reflection call to find a matching isAt method at run-time (you can check this by setting (set! *warn-on-reflection* true)). You could invoke the reflector to find and call the most specific match:

(doseq [x [(Pets$Dog.) (Pets$Cat.)]] 
 (println (Pets/isA x))
 (println "REF: " (clojure.lang.Reflector/invokeStaticMethod Pets "isA" ^objects (into-array [x]))))

Hi, in an effort to improve my coding it would be nice to read some best practices on the use of keywords (plain, namespaced and the auto namespaced). Considering topics like: • Destructuring (:person/name easily collides with :pet/name, :street/name, …) • Store and retrieve from DB (typically a string based name) • Interop with Javascript/JSON • Records (no ns support) • Specs (namespaced keys are automatically checked) • Library code and collisions. • Domain data vs other data Maybe it is too much to hope for a resource that takes all of this into account? To elaborate: While I don’t enforce any hard rules I tend to use namespaced keywords (:person/name) for domain data, auto namespaced keys for “private” data (e.g. when storing in re-frame’s app-db, I store under ::/people to indicate that this key should only be retrieved by the namespace that stored it. I’m not a big fan of the (:require [my.app.foo :as foo]) (::foo/something some-map) syntax as it’s a bit noisy for my taste with all those :: prefixing everything. But I also find myself breaking especially the domain data “rule” when JS/DB interop is involved and worst case I get an inconsistent codebase with more than one key for a given piece of data.

There’s some discussion on that topic here: https://ask.clojure.org/index.php/10380/when-to-use-simple-qualified-keywords Doesn’t have an answer for all your questions, though.

Thanks, @flowthing, that’s a nice resource to add to my list.

There's also this other in progress discussion: https://clojureverse.org/t/dont-quite-understand-rules-for-namespacing-keywords/7434?u=jjttjj

That was a nice discussion I’ll keep an eye on. I really struggle with accepting namespace qualified keywords for domain data as a good idea. Too me that feels like it introduces some unattractive coupling between namespaces that needs to work on domain data and a noisy syntax. A kind of “belt and suspenders” reaction to the fear of key conflicts. Completely ignoring data lifespan, localisation and the likelihood of conflicts in a given use case. But, very experienced developers are proponents of it so I get the feeling I’m missing something bigger here. Apart from the obvious that it won’t ever collide. Possibly we just don’t agree on the trade-offs involved though… 🙂

Hi all. I thought I knew how laziness works in functions like map and filter but I was just caught by surprise with this code:

(->> [nil "hello" nil nil]
     (map #(do (println "processing " %) %))
     (filter (comp not nil?))
     first)

processing  nil
processing  hello
processing  nil
processing  nil
"hello"

Hah! The lazy seqs produced by map and filter are chunked.

The lazy seq produced by calling seq on a vector is chunked

map and filter return chunked seqs if given one

not really what you asked but fyi you could use some? instead of (comp not nil?) and (some identity) instead of

(filter (comp not nil?))
     first

(some some?) -- identity will not "match" false but (comp not nil?) will.

Also (comp not f) == (complement f)

Right, missed the false case, thanks! (some some?) returns true/false instead of the actual item though, which I don't think is the desired behaviour here (on the other hand there's probably no "desired behaviour", since this is just an example anyway)

Ah, good point. You can't actually use some if you want false as a match.

(since some only returns "logical true" values)

So we're both wrong, for different reasons 🙂

(keep identity coll) will at least return false so (filter some?) and (keep identity) are the same I believe.

I think namespace keywords "appear" strongly encouraged but are not

They're a useful feature to have when you need it, but most of the time you'll be fine with unqualified keywords

Like I answered in that latest ClojureVerse question. If you're going to collocate keywords with a risk of collision, then they are a good way to avoid that, such as Spec's use of them or Datomic. They also allow collocated keywords to still be grouped, which is what Datomic does.

And they're nice too if you want contextual lineage.

But those are the less common use cases, in practice you will most often just have keywords inside map that represent entities, or as a way to club function inputs/outputs together, and unqualified keywords is the norm