C or zig style? Yes

[Pyrolistical]

In zig-gamedev/zig-gamedev#261, in regards to the zflecs style @michal-z said

Also, it will be easier for the users to follow flecs C code and port it to zig.

I believe we can achieve both in most (if not all) cases.

For example,

// current C style 
fn move(it: *ecs.iter_t) callconv(.C) void {
    const p = ecs.field(it, Position, 1).?;
    const v = ecs.field(it, Velocity, 2).?;
    ...

// ziggified style
fn move(it: *ecs.iter_t) callconv(.C) void {
    const p = it.field(Position, 1).?;
    const v = it.field(Velocity, 2).?;
    ...

We can keep both as the ziggified style only requires duplicating fn field into the iter_t struct.

Another example,

// current C style
const world = ecs.init();
defer _ = ecs.fini(world);

ecs.COMPONENT(world, Position);

const bob = ecs.new_entity(world, "Bob");
_ = ecs.set(world, bob, Position, .{ .x = 0, .y = 0 });

// ziggified style
const World = ecs;
const world = World.init();
defer _ = world.fini();

world.COMPONENT(Position);

const bob = world.new_entity("Bob");
_ = world.set(bob, Position, .{ .x = 0, .y = 0 });

To achieve that, I believe we only need to make zflecs.zig a top-level struct of type World, but also keep non-world static functions like fn field and other constants.

World would hold the pointer to world_t.

Is this desired direction zflecs should head in?

[michal-z]

Yes, this direction seems fine to me.

[Olle-Lukowski]

I am curious, do you need any help with this? I am willing to contribute to get this done, since I am going to use zflecs for my game engine.

[Pyrolistical]

You can lead this effort. I'm not working on this at the moment

[Kyren223]

I started on this for my own project, I cloned zflecs rather than just wrapping it in my project so it'd be easy to merge upstream if you would want.

this is the repo https://github.com/Kyren223/zflecs
it'll get updated pretty often in the next couple days, as I will be adding new things on a when-needed basis, feel free to merge it back whenever you feel it's ready (I added a flag for it in the build system and it still allows access to the current bindings), feel free to also ignore this, it's mostly for my project so it's fine if it doesn't belong upstream

[Srekel]

Interesting. I don't mind merging this in once it gets more mature but I am slightly concerned about keeping both up to date (flecs APIs do change even with small updates).

If I were you I would try to figure out a way to auto-generate these bindings. Basically look for functions of shape "fn ecs_obj_myfunc(o:Obj, ...)" and convert to Obj { pub fn myfunc(...); }.

But maybe it's not quite that simple.

Either way I would suggest writing unit tests that are paired with the regular unit tests.

[Kyren223]

Generating it is probably the right approach but I am fine doing it manually as I'll mostly add common APIs/APIs that I use, the idea is partial idiomatic API and fallback to the auto generated in rare case is better than only auto-generated

I'll def look into writing unit tests as the only way I can test it right now is manually testing it with my project.

I will open a PR once I think it's more mature (in about a week or so probably)