Parent -> ChildOf, Children -> ParentOf #17427
Conversation
alice-i-cecile
added
X-Controversial
| pub struct Children(Vec<Entity>); | ||
| pub struct ParentOf(Vec<Entity>); |
There was a problem hiding this comment.
Personally I prefer Children. Much like I think TeacherOf should probably be Students and EmployerOf should be Employees. It doesn't fit every case, but where one "owns" another and there's a good plural form of it, I feel like that kind of naming works.
The whole "is a" vs "has a" is confusing anyways since you'd say "this entity has Health" not "this entity is a Health" (but not so for things like Player).
There was a problem hiding this comment.
It comes down to how much everyone wants to stick with a central, un-lintable naming scheme. It is possible to adhere to IsA, for example a Health component would be something like Mortal and/or Destructible instead.
| #[cfg_attr(feature = "bevy_reflect", derive(bevy_reflect::Reflect))] | ||
| #[cfg_attr( | ||
| feature = "bevy_reflect", | ||
| reflect(Component, MapEntities, VisitEntities, VisitEntitiesMut, FromWorld) | ||
| )] | ||
| pub struct Children(Vec<Entity>); | ||
| pub struct ParentOf(Vec<Entity>); |
There was a problem hiding this comment.
Alternatively I like XTo as well. And it may be possible to use that sort of naming convention to convey certain meaning such as ownership or directionality (or sources vs targets).
But yeah this might just be my own personal preference haha
Fixes #17412
Objective
ParentandChildrenuse the "has a X" naming convention. There is increasing sentiment that we should use the "is a X" naming convention for components (especially relationships, following #17398).This is embraces that by doing the following:
ParenttoChildOfChildrentoParentOf@cart's Thoughts
XOfandXBynaming convention helps indicate that a component is a relationship. We don't see these names much elsewhere in the wild, so it is a reasonably strong indicator that a given component is a relationship. And it helps resolve the ambiguity ofParent(is it a parent, or does it have a parent?)RelationshipTargetside (ex:ChildrenvsParentOf). There are a lot of use cases where the variable name would really benefit from beingchildrenand notparent_of. Iterating or indexing aParentOfis harder to mentally wrap my head around compared to iteratingChildren. Having seen the effects on the code using these APIs, I'm kind of biased toward using the plural / "has a" naming convention (Children), while still moving to theChildOfconvention for actual Relationships. Curious what yall think. I'm still not sure where I land.This is just the implementation PR. To discuss the path forward, do so in #17412.