Repository navigation
Better names for Types. #163
Description
Activity
Well, this name was chosen because:
nfdbecause in C we don't have namespaces, but we want to minimise the possibility of name conflicts with other libraries (this is common practice by many well-known C libraries, e.g. GTK, SDL, and D-Bus)opendialogis what we call the open file dialog on NFDe, and this has been inherited from the original NFD that wasn't written by meu8is for the UTF-8 version, as opposed to the native versionargsbecause this is the struct for the arguments_tbecause we already have this convention in nfd.h
That's not what I meant. I meant common practices like using camelCase or using underlines(snake_case) to separate out parts of words, making the types readable. I'm honestly confused, I didn't think I'd have to explain this.
Thanks for clarifying. I agree that the current naming convention for types isn't the most readable. However, that ship has sailed and I am not sure that the benefit of better type names is worth the extra complexity of maintaining a separate interface. If you are using C++, perhaps you could consider the C++ bindings (https://github.com/btzy/nativefiledialog-extended/blob/master/src/include/nfd.hpp)? Otherwise, you could write your own wrapper over nfd.h (which really only needs to be a single header containing a bunch of typedefs). NFDe will not break API compatibility without a major version bump (for which there is currently no reason to do), so you do not need to worry about incompatibility with future upgrades.
Is there a chance of that wrapper header file getting accepted into the main repo? I'm down to work on it if I can contribute! I'm using just C, so the header file is currently the only option. What I meant by a separate interface is just more typedefs inside the nfd.h file, maybe even using something simple like a Python script for renaming everything if it still follows a naming convention. This shouldn't break anything, but offer users a much better experience imo. You could also do it backwards, rename the types into the modern, properly named versions and then include typedefs for backwards compatibility too. Thanks for your explanation, if it's not possible I can understand but not many people are going to be willing to make a typedef header file for a library they're just trying out, like I was.
Is there a chance of that wrapper header file getting accepted into the main repo?
I am not sure at this point. You are the first person in the few years this library has been around who has raised this point, so I am wondering if it is really as big of a problem as you make it out to be.
If it were to somehow make its way to this repo, though, it almost certainly can't be a Python script. I think it is not worth introducing Python as a build dependency.
Given how library/tools like NFD are frequently "setup once, and forget", I don't believe it's worth the bug-inducing risk trying to change the names to snake_case (certainly not camelCase). I know, I know, people will say "but it's just a simple search-replace", believe me, something will become a bug.
Better to just leave it "as is" imo.
Well, typedefs are more just getting names programmatically and having an interface addon to the .h file users import. It won't cause any bugs and any name conflicts will be instantly detected by compilers and modern LSPs like Clangd. I was going to suggest a python script to generate this .h file, probably named
nfd_proper_api.hbut since Python understandably doesn't seem like a desirable build dependency I could try to come up with a script or a .sh file that just does some greps, pipes, and replaces.Also, leaving a bad API "as is" after it's being used in production and is known to have a terrible API is a bad practice and steers users away. I would only suggest something like that when the names are something that are never touched, or barely used in some obscure internal API. This is a User Facing API, which deserves proper care for the user's sanities. Changes to user facing APIs are common in even enterprise level applications, and this is an extremely non-intrusive way to do it with just an additional header.
Most/all developers are just going to wrap the standard examples provided in to their own fn call and that's "the end" of the integration.
This sort of refactoring/rework feels needless. Naturally I'd say go right ahead with what you want to do for your own setup/fork of course.
I'd hardly call this API "terrible", far from it.
Sorry, I meant Bad API as a generalization of other APIs that change, and a generalization of the issues they have similar to this one. I think the overall API of this library is great, but clearly just have a bit of issue using it with the names given. Also, I don't think you're getting the point after about 3-4 comments back and forth. This is not a refactor of any sort, this is an additional header that could be used to provide an alternate naming scheme. Creating my own fork of this won't really be useful as most users will still come by here, and it'll be hard to discover even though maintenance is minimal.
Also, what you said about wrapping a library in functions applies to almost all libraries. That should never mean you never try to create a better user experience either way.
I love this API, and love that it provides a simple interface. I just hate using the type names, because I cannot understand them no matter how long I look, with words morphing around each other, and most of the types being impossible to remember. Is there any way you could provide a more updated, separate interface with more conventional type names so it's much easier to put them into functions or declare variables?
Example Type name:
nfdopendialogu8args_tThank you!