if fileExists(someName) or dirExists(someName)
...although the OS APIs usually provide the neutral stat() function - or some equivalent. Using the xExists() procedures twice, seems quite a bit of overhead to me. Is there any other/better solution (except for abstracting the respective API calls myself)? What about a neutral function like "ifExists(someName)"?
Determine if a specific name (be it a file or a directory) exists BEFORE renaming a file/directory to that name (this is however just an example). IMHO the problem here is that we have to know beforehand what we are going to test for, while some ifExists() function (just to give such a function a name) would be type-agnostic.
I could really live with a potential ifExists() and w/o fileExists() and/or dirExists() given that we have getFileInfo() - the latter of which IS ignorant to what is behind a specific handle or file name.
As there is probably good reason to have fileExists() and dirExists() in the library, why not just add this other function?
Well all examples I can come up with for ifExists encourage race conditions. Ok, ok, fileExists and dirExists do that too, but here the use case I can come up with is "if it is a directory, process every file in it, if it is a file, process it directly".
As there is probably good reason to have fileExists() and dirExists() in the library, why not just add this other function?
Maintenance costs. Note that getFileInfo was added after dirExists and fileExists.
Araq: race conditions
Avoiding race conditions in the filesystem requires transactional locking; without it, concerns about race conditions are pointless ... files and directories can be created or removed at any point by other processes. And separate fileExists() and dirExists() functions create more opportunities for race conditions than a single pathExists().
Araq: Maintenance costs
There are more maintenance costs for two functions than for one. I suggest either replacing fileExists() and dirExists() with a single pathExists(), or do away with them altogether. A good reason for the latter is that it is impossible for fooExists() to be accurate ... inaccessible directories in the path make it impossible to know whether the file exists or not.
AxBen: Determine if a specific name (be it a file or a directory) exists BEFORE renaming a file/directory to that name (this is however just an example)
That's a pretty good example ... in other cases you can usually just try the operation and respond appropriately if it fails, but a rename removes the target file if it exists (at least in POSIX; I'm not sure about Windows because it's so poorly specified) and you may well not want to do that. But note that you can just use fileExists() here ... if the target is a directory, the operation will fail.
Some other arguments for a unified function (I suggest the name pathExists()):
On some systems, querying whether a path exists is cheaper than getFileInfo because it's just a lookup in the parent directory, and no need to read the attributes. (On POSIX, pathExists() can be implemented with the access() function rather than stat(), although I don't think it's cheaper.) And one can have generic (functionally, not typewise) functions that take pathnames as an argument without any concern with what sort it is, and having two functions just gets in the way. In fact, I can't think of any way in which having the two functions is better than having a single pathExists() function, and in almost all circumstances, a call of either of the two functions could transparently be replaced with pathExists() ... and in those cases where it makes a difference, using pathExists() has a better outcome (being told that a file doesn't exist, when a directory of that name does, or v.v., will often result in undesired behavior). So, all in all, having separate fileExists() and dirExists() instead of a single pathExists() is inferior design, IMO.
Araq: My question is: Why can't you simply use getFileInfo() and call it a day?
Note that my comments above address what should be in Nim, and were written before I saw this comment. As for what AxBen or any other user of the current language should do, I agree ... getFileInfo() gets the job done (although I think it's unfortunate that it throws ... existence and accessibility are unexceptional info).
There are more maintenance costs for two functions than for one.
But the 2 functions already exist (!), so we would have to deprecate them etc. for your "superior" design which happens to not address the real use cases of dirExists and fileExists at all!
Don't expect any further answers in this thread from me.
First off,the best way of testing the resistance of a file is to act upon it, and handle any returned errors.
Personally, I wouldn't mind an exists procedure - the code would be relatively simple, and could be shared in some cases between the other file system procedures.
Araq: But the 2 functions already exist (!), so we would have to deprecate them etc.
Um, you're not even at version 1.0 yet. Deprecating functions at this point is of course not zero cost, but it's relatively low, and it's not a maintenance cost. Avoiding maintenance costs is precisely why deprecation is done.
Araq: your "superior" design which happens to not address the real use cases of dirExists and fileExists at all!
That simply isn't true. As I said "in almost all circumstances, a call of either of the two functions could transparently be replaced with pathExists()". And on the other side, I also noted that for AxBen's example he could just use the existing fileExists().
I also gave several arguments for why pathExists() would be superior to fileExists() and dirExists() that haven't been addressed, while at the same time agreeing that the existing getFileInfo() provides all the needed functionality, and that a good approach would be to avoid any xxxExists() function because it's impossible to reliably answer the question. Also a single pathExists() function is not "my" design ... let's not fall into the trap of attaching our egos to our creations and thus feeling personally attacked when they are critiqued.
Varriount: First off,the best way of testing the resistance of a file is to act upon it, and handle any returned errors.
As I noted, but I also pointed out why it doesn't apply to AxBen's example: "in other cases you can usually just try the operation and respond appropriately if it fails, but a rename removes the target file if it exists".