Example rescope

[Algias]

This is an example of re-scoping the raylib library and the raylib-cpp classes. This sort of thing has to be done across all files as there are a large amount of dependencies within one another.

What this achieves is that it separates the raylib and raylib-cpp functionality into separate namespaces to prevent pollution of the global namespace with raylib functions i.e raylib functions will not be called "on-accident" by calling or utilizing raylib-cpp api.

Currently, raylib functions are callable from the global namespace and thus can circumvent going through the raylib-cpp class. This can be seen in many of the examples where a mixture of raylib and raylib-cpp api are used despite raylib-cpp equivalents existing.

This is not the most elegant solution, but I had trouble with getting nested-namespaces working properly due to the ambiguity between the class and struct names.

Ultimately I believe this is just a matter of philosophy regarding the wrapper design, and really is mostly trivial.

[RobLoach]

Interesting idea. Would increase verbosity, and save from namespace collisions. You're right about it being needed to happen across all files. Mind if we keep this PR open to get some other's thoughts on it?

[Hamondorf]

I would definitely like to see this addition if possible.

[Algias]

I'll take a look again in the near future and see if I can make it happen!

[RobLoach]

I'm unsure how this would be reflected in other spaces. While it does make sense, it is changing how people would use the main raylib API, so I'm going to close this for now. Thanks!

[marinedalek]

I'd tend to agree with Algias's suggestion here. If raylib-cpp is to be an "idiomatic" C++ wrapper, then it ought not to transitively dump names into the global namespace when included. My opinion is that changing how people (i.e. C++ users) use Raylib is the whole point of such a wrapper. Any and all functionality should be presented in the raylib:: namespace and the choice of whether to expose that in the global namespace left up to the consumer of the header.

My own preference would be for the low-level C raylib functions to be present in a nested namespace, perhaps raylib::impl:: , to signal to users that they should be using the high-level OOP/RAII constructs rather than the C underpinning. Even then, a determined user would be able to use the header in the current "mixed" mode by adding using namespace raylib::impl; to their source file, while everyone else enjoyed a clean, unpolluted global namespace.