markmandel / brute Goto Github PK

Need to get a wercker box up and running, especially since we're supporting both cljs and clojure. Be great for everyone's small pull requests.

Not sure what is going on, but need to fix this.

I've noticed that now we have cljx, if I run (autotest) from the repl, then when files change on the file system (I'm usually running lein cljx auto at the same time), it will re-run the tests, but it doesn't load any changes in the files.

Ditto for when I refresh or refresh-all from tools.namespace.repl.

Loading the files into the REPL is fine, but I'm very used to my workflow with autotest and refresh, so I don't want to lose that.

@Janiczek you seen this one before?

I don't think you need to pass in the atom, I'm pretty sure you could create one and just make it part of the function context, which would make things simpler.

Now that we have reader conditionals in Clojure 1.7, we no longer need cljx (also it's deprecated).

Time to make the move!

What's the reason of using random UUIDs for entities instead of, for example, integers (as you'd see in SQL databases)? Is your only concern guaranteeing that your ID-generating function never repeats itself?

Considering integers:

• creating an atom with the counter would probably suffer from the same singleton state bug as #1 - I don't think you could have a guarantee that somebody wouldn't reset! the atom back to 0 (which would cause you to start overwriting the entities). Maybe some good encapsulation would solve this, but nah, after the change from global atoms to everything in the system, this would feel like a kludge.
• having another key in system (something like {:last-entity-id 12}) would guarantee no repeating IDs but would cause you to change the API: (create-entity system) has the problem of need to return both the changed system and entity ID. You'd probably have to create a function (get-last-entity-id), which is not very elegant.

I think I understand the reason for the use of UUIDs now: you can create new one without knowing the last one. Is that correct? Or is the reason different?

What would be a performant way to get entities with multiple components with the current implementation?

In reading this library, one thing stuck out to me like a sore thumb: every single facet of your CES is stored inside a set of globally shared atoms. This means that it's impossible to do simulations in your CES, it's impossible to have more than one CES at once... and to boot the global singleton pattern is a code smell in Clojure.

this is the CES that I built previously. The great advantage of modeling a CES this way, is that you can drop down to using a single shared ref if you have to, and when you don't, you can extract the value, update it functionally, and play with it as you see fit.