Throw exception when creating more than 1 unique entity

[sschmid]

context.isPaused = true; is the generated api for [Unique] components.

var e = context.CreateEntity();
e.isPaused = true; // currently works

The code above should throw an exception to enforce unique entities

[FNGgames]

I dont think you should throw there unless the unique entity already exists. If this is what you mean, feel free to ignore below (i have no problem with the exception being thrown for a 2nd entity being created that conflicts with the unique first entity).

If what you mean is that the entity level (as opposed to context-level) api should be depreciated, i would be in trouble. It would break a ton of my code.

I like to create a unique entity to hold several other components, e.g. a settings entity with several non-unique components attached as the actual settings data. This way i can have easy access to lots of data through context.settingsEntity.settingA.value but also get the benefit of reactive systems and groups that trigger when certain combinations of these components are added or removed. I use this extensively for scene management, input, etc, where i need reactive systems to be able to trigger on combinations of components on the same entity but i also want the benefit of a context-level reference to the entity.

Does that make sense?

[sschmid]

Clarification: e.isPaused = true should only throw, if there is an entity with this component already.

It will still be possible to flag entities like this.

[ethankennerly]

I share this concern about enforcing unique components in order to avoid having to do a query if other entities are already applying the not-necessarily unique component.

In the case of a unique component, have you considered removing the generated API for adding and removing a component to an entity?

In this example, do not generate e.isPaused property.

Instead, the context already has context.isPaused property.

And it already has context.pausedEntity entity.

As a user, I would rather not have an API than have an API that punishes me for using it.

Since the context has a way to add the component and for accessing the entity, all the valid use cases are supported, and none of the invalid use cases are left as traps for a user to stumble into.

@FNGgames brings up an interesting use case, which would modify the generated code that I saw for the context context.isPaused = false. In my version of Entitas, setting that not only removes a component, it also removes the entity. With this suggested use, I imagine it would be compatible to keep the entity with the component removed. Then context.settingsEntity can be used for other properties. If those properties are unique, then an example call like context.isPaused clarifies that the property is unique.

I could imagine this suggestion being backward compatible if it were an optional toggle on the Jenny code generators, named something like "Entity (Disregard unique attribute)".

[sschmid]

I'll take it back :D This will stay valid and won't throw

e.isPaused = true;
e.isPaused = true;