I’m trying to refine a simple example of an ECS implementation by defining behaviours for each element of the ECS pattern. I’m just curious about the best way to organize modules, examples, and tests.
Behaviours without code that consumes them seem odd; usually they are used to communicate “this generic functionality needs the following callbacks for your specific needs”, like how you implement the GenServer behaviour and then pass that module name to GenServer.start_link.
1 Like
Yeah, I guess I phrased my question poorly. I just meant provides the behaviour callbacks without specific implementations. So for instance, GenServer is a good example but it’s not a standalone lib, so I’m just wondering how such a lib would be organized. Swoosh has a nice example of this with the adapter specification, but it is bundled in with the larger suite that makes it harder for me to figure out what is the simplest structure necessary. Maybe I’m over thinking it.
Hi, @stevensonmt!
I’m trying to introduce this approach in a project I’m working on to make business logic a little more explicit and to help onboard new developers. It goes something like this:
One project holds all the contracts that define how we interact with “objects” from the domain, those behaviors act like interfaces, that are later implemented by the “real” project, which must satisfy the specification. It’s pretty straightforward.
Another good example that you already mentioned, is how adapters in most library work.
BTW, IIRC a library that also does something like this is Cameonin; which is just a specification for password hashing libraries.
PS.: If you are planning on implementing ECS using processes, bear in mind that your might have a bottleneck. I’d recommend watching this video about it a Dwarf Fortress simulator in elixir:
1 Like
Thanks! Comeonin is exactly what I was looking for as a model. Regarding the ECS implementation, this is really just a learning exercise so I’m not too worried about the bottleneck potential right now. I’ll check out the video though to avoid any avoidable design mistakes.
1 Like
If I can jump in on this, I’m doing something similar. Im working on a small library that lets the user send prompts to the openai api. All prompts have the same generic behavior but for organization reasons I’d like to keep different prompt strategies in separate modules. Does this make sense to create a custom behavior or would you just make gensever work?
The reason I’m looking at this pattern is to maximize flexibility for users of the lib to implement their own variants of each “type”. I think that’s what Comeonin has done as well. I’ll defer to others on the idea of using this pattern for code organization/readability.
Just out of curiosity, how could ECS in Elixir be practical considering there is no performance gain from memory locality?
Well, again, I’m doing this strictly as a learning exercise so practicality is not the point. That said, I think the ECS pattern is a very nice organizational framework that makes intuitive sense. Long term what I’d like is something that can use rustler to lean on legion or shipyard or other ECS crates for performance via adapters that implement the behaviours I’m trying to define.
1 Like
