Fork me on GitHub



I’ve been trying something different and bundling functionality together using protocols+records. Now I have a situation that I need to take an instance of a record and say that something happened, now this thing can do these other things as well. And what I would rather not do is just create a new concrete type… I’ve been thinking that maybe I should fall back to multimethods or perhaps I should be using multimethods in the first place… Not thought about this a lot, yet, so just wondering if this is well trodden ground.


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


Thanks =)…


is there an idiomatic way of doing sorted-map equality?


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.