Fork me on GitHub
#clojure-uk
<
2020-02-29
>
guy11:02:56

morning!

folcon12:02:16

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.

fmjrey14:02:34

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

folcon14:02:37

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

fmjrey14:02:17

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).

folcon15:02:54

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

folcon15:02:41

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…

fmjrey17:02:30

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.

fmjrey17:02:31

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

folcon17:02:40

Thanks =)…

mattford16:02:30

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

mccraigmccraig16:02:17

doesn't = do the trick ?

mattford16:02:45

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

mattford16:02:10

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

mattford16:02:14

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

mccraigmccraig21:02:39

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

mccraigmccraig21:02:21

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

mccraigmccraig21:02:47

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

mattford22:02:40

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

mattford22:02:14

(which required the original = test also)

mattford22:02:23

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