Use multimethods for logic that differ depending on the parameters to the function, meaning instead of nested if, cond, and so on.

Yea, I’m getting the impression that I’ll need to do that =)…

I'd say avoid using protocols for business entities (those that are typically saved in a DB). Instead use protocols for system components so you can have different implementations, so for things that have behavior, not data (though you can have processing state).

That’s fair, in general I do that, in this specific case I’m trying to work out how to organise a fairly complex simulation and trying to work out how to: 1) Keep the complexity down 2) Ensure that only entities that have certain qualities (components) can do things 3) Keep things reasonably fast

So I started with protocols because of 3, and I’m now realising that because my entities in my sim can gain and lose components this leads to types being a poor fit as I can’t just union them, which leads to two solutions: 1) Model types one level down, so they’re just a set or vector inside the entity 2) Keep things to just being maps. Maybe namespaced maps…

I see, protocol polymorphism is tied to the class/type of an object, but your use case requires polymorphism at instance level, so I'd avoid protocols and use some sort of :qualities vector entry on which multimethods can do polymorphism.

You could still use protocols for class level polymorphism and add multimethods on qualities, if there is a nice split between both

some inspiration: https://github.com/markmandel/brute/blob/a4a374231393da0a3c652c7af40de7c676101443/src/brute/entity.cljc#L38

Thanks =)…

doesn't = do the trick ?

Not quite, it doesn't check ordering, which for a sorted-map is odd to me.

There's a note in the equality docs about this.

I'm just grabbing the keys for the time-being and making my tests look ugly.

you mean you want a false result if the ordering is different?

ha, I've never thought of sorted-map like that

is (= (seq a) (seq b)) what you want then?

yes, that's better than my s/seq/keys version

🙂

(which required the original = test also)

actually maybe I'm just being stupid...if the ordering is guaranteed then not checking the ordering on equality is perfectly fine.