-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Open
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsC-FeatureA new feature, making something new possibleA new feature, making something new possibleD-ComplexQuite challenging from either a design or technical perspective. Ask for help!Quite challenging from either a design or technical perspective. Ask for help!S-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!This issue is ready for an implementation PR. Go for it!X-ContentiousThere are nontrivial implications that should be thought throughThere are nontrivial implications that should be thought through
Description
What problem does this solve or what need does it fill?
Earlier I opened a similar issue regarding events: #21384
With PR 21408 attempting to fix the issue for entity events, I want to apply similar changes to the relationship API.
Current problems:
- The current implementation of
derive_relationshipagain makes hard assumptions about the underlying field being exactly an entity and nothing else. Similar toEntityEvent,Relationship::getthis should work with anContainsEntitytype. - Similar to mutable vs. immutable events discussed in the PR, relationships should be immutable by default. As far as I can tell, the mutability is only required for the "fancy" relationships constructors like
EntityCommands::with_relatedorRelatedSpawner. I see no downside to disallow these functions in exchange for ensuring the relationship component is immutable. - As is,
RelationshipSourceCollectioncannot be implemented for containers of entitoids (i.e.Vec<Instance<T>>).- This is a much harder problem to solve. There is just no way to block collection mutation and keep relationships functional. I'm ok living with this, but I just wanted to raise the issue in case anyone has ideas.
What solution would you like?
I would like to solve at least problems 1 and 2.
derive_relationshipcan easily useContainsEntity::entity(self.#relationship_field)to support entitoids- We could break out
fromandset_riskyfromRelationshipinto aSetRelationshiptrait and require it for the fancier setup functions. We could then derive this trait only if#[relationship(mutable)]is specified (or maybe if#[component(immutable)]is NOT specified)
What alternative(s) have you considered?
N/A
Metadata
Metadata
Assignees
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsC-FeatureA new feature, making something new possibleA new feature, making something new possibleD-ComplexQuite challenging from either a design or technical perspective. Ask for help!Quite challenging from either a design or technical perspective. Ask for help!S-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!This issue is ready for an implementation PR. Go for it!X-ContentiousThere are nontrivial implications that should be thought throughThere are nontrivial implications that should be thought through