Add or update function?

Can you provide a bit more context about what could be “better” in your view? Obviously you could wrap that code in a function and call that function instead, but I assume you are looking for something a bit more sophisticated?

Something out of the box provided by the ECSx.Component.

• maybe add the wrapper method you suggested to the ECSx.Component macro

• maybe update would add it if it didn’t exist. If there’s a need to raise errors from update if doesn’t exist, include an update! function

• maybe add would update it if it did exist. If there’s a need to raise errors from add if it existed, include an add! function

Ironically, :ets has only a single insert that either adds or updates (overwrites). As you can see in the sauce the main difference between add and update is essentially just a guard to prevent existing elements from being overwritten, or non-existing elements from being auto-created.

There’s no upsert operation, might be worth submitting a PR.

As @smathy pointed out, :ets inserts generally allow overwrites, and this was originally how ECSx worked as well, with just a single add operation that covered both cases. The reason we separated into two functions, is because of component persistence. Take the following case:

HitPoints.add(player, 100, persist: true)
HitPoints.add(player, 95)

The first operation inserts a persistent HitPoints component with value 100
The second operation overwrites this with a non-persistent (default is false) HitPoints component with a value of 95.

What was the problem? If a user provides options to the component creation, they would have to remember those options and pass them to every update, forever. Forgetting to include the original options would overwrite with the defaults. We considered setting the options globally, but quickly found use-cases where a single component type (such as HitPoints) would be persisted for some entities, but non-persisted for others. And we want to keep the door open for future options to be added.

So the end result is that we need one function for the original creation of a component, where the options are set, and then another function for updating the component, where no options = keep the existing options.

Makes sense. Did you consider storing the opts in ETS along with the value?

The opts are stored in ETS. It’s not an implementation issue, it’s an API issue - with only one function for both add and update, it becomes ambiguous whether a user is leaving off the options because they want the options to stay the same, or if the lack of options means that they want the defaults. The only way to ensure consistency would be to demand that users include the options every time.

Oh I see what you’re getting at. I’m not sure people would expect that though (ie. that leaving options off for an existing entity would change it to the default).

Also, right now the current API doesn’t let them change the options of an existing entity at all, so you wouldn’t lose any functionality with an add that just left the opts as-is for an existing entity when the caller left them off.

Then if they wanted the opts updated on an existing entity, they’d provide the opts, which would be additional functionality.

I think the problem you saw was maybe doing an :ets.insert without doing a :ets.lookup. Obviously with that implementation you’d be clobbering existing opts for an update if they hadn’t provided them.

Or am I just missing something dumb here?

Also, right now the current API doesn’t let them change the options of an existing entity at all

This isn’t guaranteed to be the case forever.

so you wouldn’t lose any functionality with an add that just left the opts as-is for an existing entity when the caller left them off… if they wanted the opts updated on an existing entity, they’d provide the opts, which would be additional functionality.

If the default functionality is “keep the existing value” then it doesn’t work for creating new components (because there is no existing value yet). And we cannot have two different default functionalities for the same function, based on a runtime conditional. That would be very bad.

Understood.