[misc] Rename `Is*Ready()` to `Is*Valid()`

[raysan5]

Potential functions to be reviewed:

bool IsWindowReady(void);                           // Check if window has been initialized successfully
bool IsShaderReady(Shader shader);                  // Check if a shader is ready
bool IsImageReady(Image image);                     // Check if an image is ready
bool IsTextureReady(Texture2D texture);             // Check if a texture is ready
bool IsRenderTextureReady(RenderTexture2D target);  // Check if a render texture is ready
bool IsFontReady(Font font);                        // Check if a font is ready
bool IsModelReady(Model model);                     // Check if a model is ready
bool IsMaterialReady(Material material);            // Check if a material is ready
bool IsAudioDeviceReady(void);                      // Check if audio device has been initialized successfully
bool IsWaveReady(Wave wave);                        // Checks if wave data is ready
bool IsSoundReady(Sound sound);                     // Checks if a sound is ready
bool IsMusicReady(Music music);                     // Checks if a music stream is ready
bool IsAudioStreamReady(AudioStream stream);        // Checks if an audio stream is ready

[RobLoach]

That makes sense. I had originally named them Is*Ready() because I thought it matched a similar pattern in the old IsAudioDeviceReady().

[raysan5]

@RobLoach Actually I think it makes sense for IsWindowReady() and IsAudioDeviceReady() (@RenzoRomeo) but I still have doubts if it should be reviewed for all the other data structures. In any case, it's a breaking change and I'm considering it carefully...

[ColleagueRiley]

Why change something inconsequential that breaks compatibility rather than adding prefixes?

[krisvers]

With what Riley said, adding prefixes is much more important of a compatibility break than renaming Ready to Valid as there are so many namespace collisions with winapi. Although, I think that if one is to be considered, then the other should be as equally important.

[raysan5]

@krisvers Sorry, no plans to add prefixes to raylib functions.

[krisvers]

@raysan5 Why not? There are many problematic collisions with winapi, and no prefix can cause unnecessary future namespace collisions.

[RobLoach]

@krisvers That's a separate issue. For a discussion about it, see #1217 .

[krisvers]

I understand that, but if a compatibility change for functions is being considered then it makes sense to also consider other sensible function name changes like using a prefix to prevent namespace collisions.

[raysan5]

@krisvers Simbol collisions can already be avoided. I can consider slightly renaming some functions added 6 months ago but not the full library. If anyone really has that need can fork the project.

[orcmid]

@krisvers

if a compatibility change for functions is being considered then it makes sense to also consider other sensible function name changes like using a prefix to prevent namespace collisions.
This argument completely disregards all of the code in existing raylib apps out there that will suddenly not compile with such a gigantic breaking change, forcing untold amounts of work. That's not even concerning what has to change on the raylib wiki and other documentation. Whatever the @raysan5 rational for non-prefixing is, I support the conclusion.

[orcmid]

@raysan5 @krisvers

@krisvers Simbol collisions can already be avoided. I can consider slightly renaming some functions added 6 months ago but not the full library. If anyone really has that need can fork the project.

Unless there is some hideous embedding of raylib inside of a considerable Windows app, my (limited) experience is that dependencies on platform functions that require windows.h can be isolated in safely named functions compiled from separate source files that #include windows.h and are statically linked with the raylib app. That turns out to be a clean way of platform-dependency isolation.

[krisvers]

Yeah it is fair to consider that the addition of a prefix would break almost all backwards compatibility. However, a prefix for this project should have been from day one especially with many function names being the same as in other mainstream libraries like the winapi. You can't change the past though 😔

[raysan5]

many function names being the same as in other mainstream libraries like the winapi

@krisvers This is not true. Afaik, only 2 function names could potentially collide and it can be avoided.

[ColleagueRiley]

many function names being the same as in other mainstream libraries like the winapi

@krisvers This is not true. Afaik, only 2 function names could potentially collide and it can be avoided.

Iirc, it was more than two, also including starts like Rectangle which share function names.