Concept for symbol names

[DerKarlos]

We may define a concept for the names, we use for symbols.

• Some years we added the compiler type like iName or n8Name. Not needed, tools are showing the type now.
• The os/Bevy API uses its own types, also shown by the tools. Well mostly. Sometimes it may be just a Vec3. In this cases we should specify it like "pub type ScenePos = glam::Vec3;” We can’t add our own functions to “type”s? Or can we, instead define the same struct again?
• And our code also uses its own types. See Replacing native types by functional names? #39
  So we may use symbols naming the purpose, not the type. Well. Sometimes it’s the same anyway.

A challenge for this concept is the Bevy Resource Transform. Let’s ignore the big-space for a start. So Transform can be splittet in Translation and Rotation. But Bevy-ECS does not have extra types for them but uses Vec3.
A) Both may have world- or relative/delta/diff-meaning.
B) Because we use the Earth in its real size and sphericity, the “flat” surface, the OSM-Tiles are orientated to, is gone! But we should provide functions to calculate between word- and surface-values. So shall we use “type” or in the naming style?
C) And now consider big-space. The Translation may be local inside a grid as Vec3
or big-space (grid,local). Again wie could invent types or clarify it by the symbol name. Even write an issue to big-space to get extra names.

We could start with a wiki page and invent "roles" and examples.

[oli-obk]

Because we use the Earth in its real size and sphericity, the “flat” surface, the OSM-Tiles are orientated to, is gone! But we should provide functions to calculate between word- and surface-values. So shall we use “type” or in the naming style?

We have TileCoord and TileIndex for this. They have methods for converting to and from Cartesian coordinates

[oli-obk]

And now consider big-space. The Translation may be local inside a grid as Vec3
or big-space (grid,local). Again wie could invent types or clarify it by the symbol name. Even write an issue to big-space to get extra names.

I can create a helper like Player to handle transform + grid together with helper methods

[DerKarlos]

Your comments are good for #51 and "Player" may also be a good idea. I will write for details there.
As long as we use our own types, it is fine.
I will give concrete undefined examples here later