-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[misc] Rename Is*Ready()
to Is*Valid()
#3930
Comments
That makes sense. I had originally named them |
@RobLoach Actually I think it makes sense for |
Why change something inconsequential that breaks compatibility rather than adding prefixes? |
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. |
@krisvers Sorry, no plans to add prefixes to raylib functions. |
@raysan5 Why not? There are many problematic collisions with winapi, and no prefix can cause unnecessary future namespace collisions. |
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. |
@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 |
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 😔 |
@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. |
Anyway, this is a pointless discussion, this is my final message on the topic. If you have some complaint, probably better direct them to Microsoft and Winapi than raylib. |
What? Raylib colliding with Winapi is not a problem with Winapi, but instead Raylib lol. Though there are annoying things like near, far covered by defining the lean and mean macro. Considering how you are against breaking compatibility, what do you think would happen if Winapi changed to suit a C game library. This isn't exactly a pointless discussion but I will yield. |
Stop diluting this issue. I've created a discussion for windows.h conflicts at #3945 . Feel free to discuss naming conflicts there. |
For the sake of historical tidiness, it is valuable to know that BGI, the Borland Graphical Interface inspiration for raylib was used on MS-DOS forms prior to Windows. No matter. Platforms will continue to change and require adapter layers of one kind and another while keeping the essential API of raylib stable. So long as the implementation is in ISO Standard C, the handling of libraries and other dependencies will be anchored accordingly. |
This is a good idea to make the API more intuitive, however it would break compatibility with many existing projects. I just don't see the point of breaking thousands of projects with these renames. I believe the function/enums naming should be well considered before they are pushed into master. It seems to late to fix it now. The only solution I see is to keep the old functions and add new ones that call the old ones: void newFunctionName() {
oldFunctionName();
}
void oldFunctionName() {
// DO STUFF
} This way there wouldn't be the need to break already existing projects, while improving the API clarity. However just like Ray said on Discord, [that's]
|
@luis605 The functions mentioned in this issue were added on latest release, a few months ago and they don't seem to be key functions that many users could use. I think we are still on time for a quick rename with not much pain involved. Renaming all |
@raysan5 Then I suppose you should rename the functions for better clarity, because the API naming lacks some clarity in my opinion. |
Please, could you ellaborate why |
When you use "IsReady()" to check the status of an object, like "IsModelReady()", it implies that the object is fully prepared and operational for use. However, in some cases, the object might be valid (initialized) but not necessarily ready for usage. For instance, in the context of a model, all pointers might be initialized (valid) but not fully ready for usage (ex. if the vertices count is different than the actual number of vertices in the model). Therefore, renaming the function to "IsValid()" would better reflect its purpose, indicating that it simply checks if the object is in a valid state, regardless of its readiness for use. This change in semantics would make the function's purpose clearer and more aligned with its actual behavior. |
For backwards compatibility of function names in projects, defines are an option. While raylib may not prioritize backwards compatibility, it can still be accomplished in other means... #define IsModelReady IsModelValid |
@luis605 On the other hand, I am unclear what the user action is expected to be on !Is*Valid and how this could matter. It seems from the example about vertex counting that Is*Complete or Is*Prepared might be preferable terms, and I still am unclear what action an application can take in a releasable app. I think it might also be important to be clear what the operational behavior will be when a *-operation is attempted when !Is*Valid. |
@orcmid Precisely, when an object is not valid, the best thing to do is not to use it and, if possible, reload it. Otherwise you might get into undefined behavior, segfaults, etc. which may crash the application or make it unusable. It would also be nice for this functions to have a logging mechanism to alert the developer/user what the problem is, so he/she can further troubleshoot. |
@luis605 the logging mechanism has been there for many years, when a resource loading fails it is logged.
Yes, and that's the case. We can split the loading-initialization-dataValidation in as many states as desired but it doesn't mean one syntax is better than another. What about an object that |
@luis605 > It would also be nice for this functions to have a logging mechanism to alert the developer/user what the problem is, so he/she can further troubleshoot. I can't imagine this being expected of and meaningful for a game's end-user. The closest I can think of is a AAA game reporting that something is wrong and it is closing, with a location of a log that can be used in messaging the game developer's support location. In advanced cases, submission of the log can be an option in the error dialog. If it's a debug provision, or tied into an assert, I think the !Valid case should always be treated as fatal in a release's code. This does not seem to be part of the conceptual model for raylib. I don't think I have anything useful to offer about that. |
its ok to do breaking changes so rename everything, fix and be consistent |
@jamesl-github I agree, actually raylib implements (some) breaking changes in every minor release and I'm ok with that. Here the discussion is more focused on the correctness of those changes and syntax itself. |
@jamesl-github @raylib So, if we are talking about a raylib 6 here, certainly. A 5.1 with that many breaking changes and taking over the progression seems sketchy to me. It is understandable that there are no patch releases in raylib, and there is no backporting from -dev version. That makes breaking changes more difficult though, especially if that's also the only way to get important bug fixes. |
I think this is a difficult issue because the Lines 3963 to 3967 in 6ec9255
Perhaps off-topic but if they are renamed I would support changing their definition to also return the reason for failure, though maybe that's out of scope and makes the API change more severe. Edit: |
@Fhoughton @raysan5 I think "Usable" is more pertinent. "Available" is too ambiguous. |
I initially put these functions in place to allow checking the failure state of the Shader shader = LoadShader(0, "reload.fs");
// Before
if (shader.loc == NULL) {
// Failed to load shader
}
// After
if (!IsShaderReady(shader)) {
// Failed to load shader
} I named them IsWindowReady()
IsAudioDeviceReady() I don't think there is a need to complicate it more than is needed. The real goal of these functions was for an easy way to check against the fail-state of the load functions. |
@RobLoach Thanks for the clarification, I'm still not decided on the naming, some of those function do not only check if the data is properly loaded but also if it is valid (i.e. parameters are correct for raylib use) and if it is ready (data has been uploaded to GPU and a valid id has been retrieved). With latest commit 4c9282b, an additional system has been added to allow loading some data (i.e So, again, not that simple to find the proper terminology for those assets-loading functions. That was the reason they did not exist in the first glance, instead of providing a function that could be confusing, just let the users check the values required to be checked for the specific use case; after all, all raylib structures are transparent. |
Potential functions to be reviewed:
The text was updated successfully, but these errors were encountered: