Feedback Is API in ISystem Inconsistent?

(wrote it in another thread, but want to make it a separate post)

I do not understand why api for working with entities in ISystem is split into three separate parts. I do not understand the guiding principle behind such organisation.

1) state.EntityManager.
2) SystemApi.
3) state.

So here I am developing my ECS project with ISystem.

1. I need an entity. How do I get (EDIT: create) it? From state, as the easiest shortest way? No. From EntityManager inside state? Right! Okay, longer but I guess makes sense.
2. I need a singletion. Let's see "state."? "state.EntityManager."? SystemAPI? Got it, but why SystemAPI?
3. Now I need to get a buffer from that singleton. SystemAPI? No. Now it's in the "state." Why?

I personally would write extension methods to do everything via state but SystemAPI stopped working outside systems.

 

1.
Retrieving component data on an entity can be done through ComponentLookup/BufferLookup, EntityManager, and SystemAPI, so that's probably not what you meant. What do you mean by "I need an entity?"
2.
SystemAPI only serves to hide the guts of what's actually needed to do the things you ask, indicating to the appropriate source generator(s) that code to support the intent of the usage should be written behind the scenes. You would equivalently create an EntityQuery via SystemState, then access the singleton through the EntityQuery. You don't "have" to use SystemAPI. Some people don't, and just create their own queries, perhaps because they value increased transparency (for example, better estimates of how many queries you're using on a system) or prefer parameter-passing everything on utility methods without relying on SystemAPI.
3.
What do you mean by getting a buffer from a singleton? Do you mean a DynamicBuffer attached to a singleton component (inadvisable to specifically depend on this if so - the general pattern is treat each singleton as its own singleton irrespective of where other singletons are or whether they exist) or a singleton DynamicBuffer on a "singleton entity" (troublesome terminology at best, unless this is referring to a singleton of an archetype)?

The real meat of entity manipulation is either through structural-changes-capable EntityManager/EntityCommandBuffer, EntityQuery for accelerated singleton access and general querying, or the job-friendly ComponentLookup/BufferLookup. Getting access to EntityQuery/ComponentLookup/BufferLookup happens through a SystemState. In general, any "inconsistency" is just the API surface of SystemAPI not capturing a use case.

 

I didn't give the best examples, also some things were unclear and misleading (wrong). Trying to illustrate things that can be done only in one of three ways. ECBs, queries and lookup iterations aside.

1) Creating entity only via EntityManager?
2) Getting a singletion only via SystemAPI?
3) Getting a lookup via state?

It does seem clearer now..

1 - makes sense to begin with. Personally I'd shortcut everything via state, but can understand those who would object
2 - why not via state? now makes more sense if it's just a shortcut for a query and can be done from query. Also I get that code gen optimises SystemAPI for the systems, but doesn't it do it for the state as well?
3 - Still, why not system API or EntityManager? Just not clear why API is split in this way.

So, yes thank you. You also solved my blocking issue. SystemAPI was not available in extension methods but I realize now that I can indeed get singletons without SystemAPI. But I still don't quite understand..

So, personally I plan on writing a lot of extension methods to reduce boiler plate by A LOT, I did it every time working with DOTS ECS, and I don't mean that it means that the API is bad, it just needs to be extandable because in individual projects amount of code can be reduced by a lot with extensions, but this thread is not abou that. And I might just do everything via ecb and state. (state.CreateEntity, state.CreateEvent, state.GetSingleton, state.SendRPC, etc, etc) Just my personal preference.

 

SystemAPI is a codegen-based crutch introduced in 1.0. So there will be a lots of improvements to it I suspect.
And doing codegen is hard on its own. Doing it without loosing compile / editor & runtime performance is even harder.

In any case, everything can be done without it.