On Thu, Jan 04, 2018 at 06:54:12PM -0500, Jeff King wrote:
> > If we really want to be anal, perhaps a new helper path_exists()
> > that cares only about existence of paths (i.e. the implementation of
> > these two helpers they currently have), together with update to
> > check the st.st_mode for file_exists() and dir_exists(), may help
> > making the API set more rational, but I do not think it is worth it.
>
> Yep, I also considered that file_exists() probably wants to be
> path_exists() with its current implementation. We'd probably want to
> review all of the callers.
>
> Anyway, I tried to do the minimal refactoring here, with no change in
> behavior. I'm not opposed to calling this dir_exists() as path_exists()
> and making it globally available (as you note, I don't think we'd want
> to use a true dir_exists() here).
So I actually started down this road just now, but I'm not sure if it's
worth it. If we were to transition to an endgame with path_exists(),
dir_exists(), and file_exists(), we'd probably want to do something
like:
1. introduce path_exists(), but leave existing file_exists() callers
in place
2. introduce file_exists_as_file(), which checks S_IFREG
3. audit each file_exists() call to see if it ought to be
path_exists() or file_exists_as_file() and convert as needed
4. When there are no more file_exists() calls left, all
file_exists_as_file() instances can be renamed to file_exists().
But as with any "audit each..." plan, that leaves topics in flight out
of luck. If we want to be kind to those, we'd have to wait a long while
to shake out any file_exists() callers.
At which point is there much value in having path_exists() as a wrapper?
It's a better name, perhaps, but I think my future-proofing against
"file_exists() may become file-specific" was probably overly paranoid. I
don't think we could sanely do that conversion without risking breakage.
Maybe we should just document its behavior and use it here, rather than
introducing this new dir_exists().
-Peff
