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 #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