Renamed BRP methods to be more explicit.

[AlephCubed]

Fixed #18055.

Based on the discussion in the related issue, the following BRP methods have been renamed:

Old	New
bevy/query	world.query
bevy/spawn	world.spawn_entity
bevy/destroy	world.despawn_entity
bevy/reparent	world.reparent_entity
bevy/get	world.get_components
bevy/insert	world.insert_components
bevy/remove	world.remove_components
bevy/list	world.list_components
bevy/mutate	world.mutate_components
bevy/get+watch	world.get_components+watch
bevy/list+watch	world.list_components+watch
bevy/get_resource	world.get_resources
bevy/insert_resource	world.insert_resources
bevy/remove_resource	world.remove_resources
bevy/list_resources	world.list_resources
bevy/mutate_resource	world.mutate_resources
registry/schema	registry.schema

I also replaced the word destroy with despawn to match EntityCommands::despawn and other related methods.

[splo]

I wonder if the prefix shouldn't be bevy. instead of bevy/, or if it should even exist.

Here are some observations:

• OpenRPC documents require the rpc.discover method for service discovery. The spec says:

  The rpc. prefix is a reserved method prefix for JSON-RPC 2.0 specification system extensions.

  To me this hints that . is supposed to be a method separator.

• If we look at examples in the OpenRPC Playground:

  • They don't put prefixes, hinting that the whole RPC spec is already specified by the context. If we know we already are using the Bevy RPC protocol, shoulnd't we drop the bevy prefix?
  • They use snake_case: list_pets, create_pet, delete_pet_by_id.
  • The Ethereum JSON-RPC spec has web3, net and eth prefixes and uses camelCase: web3_clientVersion, net_peerCount, eth_getBalance.

There are conflicting "standards" but which one should we have (among many other variations)?

• bevy.world.components.get
• bevy.world.get_components
• bevy.world/components/get
• bevy.world/get_components
• world.get_components
• world/get_components
• world_get_components
• world_getComponents

My personal favorite would be world.get_components, but you know, I'm just one guy on the internet. 😁​

[splo]

Another random thought: should there be an entities category?
bevy/world/entities/query, bevy/world/entities/spawn , etc. Or rather bevy.world.spawn_entity.

[AlephCubed]

I wonder if the prefix shouldn't be bevy. instead of bevy/, or if it should even exist.

I would agree with dropping the bevy prefix.

Another random thought: should there be an entities category? bevy/world/entities/query, bevy/world/entities/spawn , etc. Or rather bevy.world.spawn_entity.

I did consider adding an entities category, but I think query is somewhat ambiguous. spawn, despawn, and reparent are all clearly entity methods, but query could be considered a component method instead.

As for general naming convention, I have no strong feelings either way.

[splo]

I did consider adding an entities category, but I think query is somewhat ambiguous. spawn, despawn, and reparent are all clearly entity methods, but query could be considered a component method instead.

To me this indicates that the names should follow the verb_noun pattern instead of category/verb. That removes ambiguity but also removes the benefits of neat hierarchies.

So spawn would become spawn_entity but query would stay query. With world. or bevy.world. prefix of course.

In the end the question is what will future methods be? For instance I read somewhere that future resources will be changed to become actual components. Will we always be able to fit in a category without ambiguity like query?

As for general naming convention, I have no strong feelings either way.

No strong feelings either. Just dropping thoughts before it's "too late".

[Leinnan]

@splo For me it looks fine, but I don't have strong opinion here.

[splo]

If noone has strong opinion, then I'd suggest moving on with dropping the bevy prefix and setting . as separator. So one of these:

• world.components.get
• world.get_components
  With a personal preference with the second one.

Your choice @AlephCubed!