What is the best way to invoke a function on a view of entities and on individual entities?

[Colon-D]

Hello. I was wanting to hear from others to see what their opinions were on
these different ways to do the same thing.

I apologise if this is not the place to discuss this, or if I am overthinking.

The scenario is performing any function on any entity's components.

The problem is the best way to implement this function, to easily allow for
reusing the same function on different sets of entities.

---

1. Directly work on components

#include <entt/entt.hpp>

struct read_component {
	int value{};
};

struct write_component {
	int value{};
};

int main() {
	entt::registry registry{};

	const auto main_entity = registry.create();
	registry.emplace<read_component>(main_entity, 42);
	registry.emplace<write_component>(main_entity);

	// perform function on all relevant entities
	for (
		const auto entity :
		registry.view<const read_component, write_component>()
	) {
		registry.patch<write_component>(entity, [&](auto& write){
			write.value = registry.get<const read_component>(entity).value;
		});
	}

	// perform function on one entity
	registry.patch<write_component>(main_entity, [&](auto& write){
		write.value = registry.get<const read_component>(main_entity).value;
	});
}

This has the advantage of being simple.

This has the disadvantage of duplicated code. Forgetting to change one, will
most likely cause a lot of issues. Remembering to change all instances is also
effort that should be solved through code.

---

2. Call a function that takes the components as arguments

...
void copy_value(
	entt::registry& registry,
	const entt::entity entity,
	const read_component& read,
	write_component& write
) {
	write.value = read.value;
	// notify on_update
	registry.patch<write_component>(entity);
}

int main() {
	...

	// perform function on all relevant entities
	for (
		const auto& [entity, read, write] :
		registry.view<const read_component, write_component>().each()
	) {
		copy_value(registry, entity, read, write);
	}

	// perform function on one entity
	const auto& [read, write] =
		registry.get<const read_component, write_component>(main_entity);
	copy_value(registry, main_entity, read, write);
}

This has the advantage of no code duplication.

This has the disadvantage of being slightly less simple for the view,
and not so simple to invoke manually.
Additionally, I need to manually invoke patch() as on_update does not
trigger to the getting on non-const references.
Forgetting to do this might cause issues when I am relying on on_update.

---

3. Call a function that takes the entity as an argument

void copy_value(
	entt::registry& registry,
	const entt::entity entity
) {
	registry.patch<write_component>(entity, [&](auto& write){
		write.value = registry.get<const read_component>(entity).value;
	});
}

int main() {
	...
	// perform function on all relevant entities
	for (
		const auto entity :
		registry.view<const read_component, write_component>()
	) {
		copy_value(registry, entity);
	}

	// perform function on one entity
	copy_value(registry, main_entity);
}

This has the adventages of being usable on individual entities,
and having the easiest syntax.

This has the disadvantage of a duplication of data, in that both the view and
the function have to keep what components they use in sync. A mistake could
easily be made which means the view no longer matches what the function
needs, or vice versa.

---

For now, I am using Method 2, but I feel like I am missing some easier way of doing what I want. Easier as in less verbose, and without needing to tell the registry that I have updated a component. It is not too unmanagable, so if there is not anything I am missing then I will continue onwards with this approach.
Passing in the registry and entity only to call patch() also seems like overkill, as the components have already been passed in, but the components could be accessed from the registry with the entity directly - which seems redundant.
Method 3 passes in minimal information, but mistakes are more likely. A middleground would be nice, but I can not think of what that could be.

[skypjack]

Hi, sorry for the late reply. Can I ask you what version of EnTT are you using?
With the most recent master, you can get and pass around storage classes directly to solve the problem of invoking the patch on the registry. As in:

void copy_value(
	entt::storage<write_component>& storage,
	const read_component& read,
	const entt::entity entity
) { ... }

Although the final result is mostly the same. As for the best solution, here you're literaly asking for a matter of tastes since all the proposed ones are just right.
The problem with the get-that-does-not-trigger-signals boils down to how the C++ language works. I can't really solve it and there is no way to know that an user changed something on a component through a reference.

[Colon-D]

Thank you for replying, I appreciate you spending your time to do so.
I am using version v3.10.3 of EnTT.

---

I imagine if I pass around the storage class directly, it would still need to invoke patches on it.
It does have the pro that the function can not modify components of other types, so I will experiment with it and see how I feel.

---

Indeed, I am asking for a matter of taste. I am asking as I am inexperienced and I am scared of learning bad practices. I want to use the Entity Component System to its full advantage. My reason for using it is for me to design my code better, speed is a bonus. Over the past five years I have started several projects and the code design keeps ending up bad, and I reach a brick wall. I have went from procedural programming, to object orientated, to entities and components, and finally to entity component systems. I do feel like I am making lots of progress, my code is a lot cleaner now, but I have only experience in small projects. A game of pong, a space invaders clone, etc. I want to make programs that are bigger, not by much. As I have changed designs I have lowered my scope too far because I am scared of failure. From ten minute games to ten second ones.
Now whilst good games have been programmed from the previous code designs I mentioned earlier, right now I feel most comfortable with Entity Component Systems. My path to progression with this system is blind though, and I have to solve problems differently than the other systems. Unfortunately, most information I can find online for solutions to these problems is for the other systems. I want knowledge from other people who actually have experience using ECS. I understand that ultimately, I need to have more experience myself, but I do not want to defeat the purpose of myself using an ECS, I do not want to lock myself into a design that is a step in the wrong direction.
Perhaps right now I am thinking too small in scope, and trying to solve problems that do not exist. I have a bad habit of overdesigning in all the wrong areas, and starting projects from scratch over and over again, trying different libraries to find the best, adding features where they are not needed. I am sorry to bother you with problems that mainly are a result of me thinking I am not doing a good enough job. I do enjoy discussing programming though, so if anything can come from me looking for others opinions it is that I can interact with others who hopefully enjoy programming too, not that I can add much to the conversation.

---

Although there is no way to know whether a user has changed a component, is there a way to differentiate whether a user requested a const component over a non-const component? If so, is there a way to imply that the user did modify the component if they got a non-const component?
Obviously such a feature would be undesired by everyone, and would break every project that relied on EnTT, but I am curious as to whether that is possible in C++. I have decent knowledge of C++, but not enough to do anything fancy with it. I think you have done a wonderful job on this project, and I think that you are very kind to provide support for it and to go out of your way to respond to me.

[skypjack]

Yeah, defniitely. EnTT already supports const vs non-const to address the read-only vs read-write model you're describing. That is, if I get something as non-const, I mean to write it probably. 🤷‍♂️
It works with a get, as in: auto&& [t, u] = registry.get<T, const U>(entt);, where t has type T & and u has type const U &.
It works with a view, as in: auto view = registry.view<T, const U>(). In this case, the view will propagate the constness to the returned types, both during direct iterations or when using its get.
And so on. The constness is taken into consideration literally eveywhere in EnTT. This is extremely useful when you want to deduce what resources are used by a system and what the purpose is, for example to schedule these systems with the flow class.