Fork me on GitHub
#keechma
<
2019-07-16
>
carkh06:07:02

I have a question, those behavior trees can send events, and the controller has an API to execute these. they're passed the controller itself, the app-db-atom and the event arg

carkh06:07:04

The question is, should they, in your opinion, receive the app-db-atom or just the app-db, leaving them to other devices if they want to update it

carkh06:07:06

or maybe let them return a naked app-db ... I opted for the app-db-atom thinking that's the most versatile

carkh06:07:40

Also i disagree with the direction of your <cmd arrows ! you're viewing this from the perspective of the guy that made the controller, rather than the user, and it's the opposite direction compared to core.Async !

carkh06:07:33

too late now to do anything about it though =)

mihaelkonjevic06:07:17

I use app-db-atom for lower level interfaces, because it makes it easier to build abstractions on top of it, and app-db for apis that have deref and timing guarantees. As for the arrows on cmd and sub, they are from the perspective of a component (incoming or outgoing). I think they were inspired by some re-frame wiki page with the ideas for helper apis, so I picked it up from there :)

mihaelkonjevic06:07:46

The lib looks really interesting, can't wait to do a deep dive

carkh06:07:04

hah well i was only nitpicking with those arrows =)

carkh06:07:38

There is no timing garanties in this case, those events are there to start websockets or do any number of other side effecting stuff, so i guess i'll keep it as is

carkh06:07:13

there is an overlap with pipelines, my stuff is more verbose, bigger machinery, probably a bit slower, but is more versatile and totally testable

mihaelkonjevic06:07:19

This looks very powerful, and I'll have to dig in more, but I did have cases where something like this would be a perfect fit

carkh06:07:15

let me know if you find bugs ! now back to regular app dev =)