[Filesystem V3] file_status over-design?
Both Filesystem V2 and V3 status() functions return an object of class file_status. file_status is just a thin wrapper around a file_type enum: enum file_type { status_error, file_not_found, regular_file, directory_file, symlink_file, block_file, character_file, fifo_file, socket_file, type_unknown }; It was designed that way on the assumption that file_status would eventually include additional state information. But that never happened, so it looks like over-design my part. The fix would be to rename the enum as file_status, and remove the current class file_status entirely. That would break a certain amount of existing code, but I suspect the C++ committee would force such a change anyhow for TR2, so better to get it over with now. Comments? Opinions? --Beman
Beman Dawes wrote:
Both Filesystem V2 and V3 status() functions return an object of class file_status. file_status is just a thin wrapper around a file_type enum:
enum file_type { status_error, file_not_found, regular_file, directory_file, symlink_file, block_file, character_file, fifo_file, socket_file, type_unknown };
It was designed that way on the assumption that file_status would eventually include additional state information.
But that never happened, so it looks like over-design my part.
The fix would be to rename the enum as file_status, and remove the current class file_status entirely. That would break a certain amount of existing code, but I suspect the C++ committee would force such a change anyhow for TR2, so better to get it over with now.
Comments? Opinions?
Keep the status() function but add a filetype() function which returns a file_type enumerated value.
On Tue, Feb 23, 2010 at 8:53 AM, Edward Diener <eldiener@tropicsoft.com> wrote: ...
The fix would be to rename the enum as file_status, and remove the current class file_status entirely. That would break a certain amount of existing code, but I suspect the C++ committee would force such a change anyhow for TR2, so better to get it over with now.
Comments? Opinions?
Keep the status() function but add a filetype() function which returns a file_type enumerated value.
Hum... That would ease the transition. It has also gotten me thinking about other ways to minimize breakage of existing code. More later. Thanks, --Beman
On Tue, 2010-02-23 at 20:15 -0500, Beman Dawes wrote:
On Tue, Feb 23, 2010 at 8:53 AM, Edward Diener <eldiener@tropicsoft.com> wrote: ...
The fix would be to rename the enum as file_status, and remove the current class file_status entirely. That would break a certain amount of existing code, but I suspect the C++ committee would force such a change anyhow for TR2, so better to get it over with now.
Comments? Opinions?
Keep the status() function but add a filetype() function which returns a file_type enumerated value.
Hum... That would ease the transition. It has also gotten me thinking about other ways to minimize breakage of existing code. More later.
fwiw (I haven't used filesystem so far) in a similar in-house lib we found it necessary to make the "stat" object caching and lazy. This has problems of its own, but the problem with doing otherwise is that collecting all file status info may be quite expensive (and additionally, which info is expensive to collect may be platform dependent). Further, making repeated calls to "stat" or its ilk should be avoided where possible for the same performance reasons. However, I think providing a few small/specific interfaces is a reasonable idea for ease of use without too big a performance hit in common/simple cases. So - I agree with providing filetype(), which complements size(), last_write_time() and the is_xxx() interfaces for obtaining specific dimensions of file information. I would further suggest that status() should/could eventually "evolve" to return a lazy/caching status object, but backwards compatibility is all that matters for now. Such an object should eventually provide the same set of information as the various functions that provide information via a similar interface, with the proviso that the result returned may reflect the state of the filesystem object referenced by path as it was at any time between when status(path) was called and when the corresponding accessor member function of the returned file_status object was called. This won't break existing code so long as the filetype info at least is retrieved early.It would seem trivial to extend it now to include at least the information / interfaces size() last_write_time(), is_xxx() where in the posix impl at least (and perhaps others for simplicity) all info would be obtained on the call to status(). regards Darryl.
Beman Dawes wrote:
It was designed that way on the assumption that file_status would eventually include additional state information.
But that never happened, so it looks like over-design my part.
What other information were you thinking of? Permissions? Lock state?
On Wed, Feb 24, 2010 at 6:06 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Beman Dawes wrote:
It was designed that way on the assumption that file_status would eventually include additional state information.
But that never happened, so it looks like over-design my part.
What other information were you thinking of? Permissions? Lock state?
Permissions, lock state, meta information in general. --Beman
On 23 February 2010 08:26, Beman Dawes <bdawes@acm.org> wrote:
It was designed that way on the assumption that file_status would eventually include additional state information.
Would it be plausible for vendor-specific extensions here? It seemed like the biggest obstactle to providing more was portability, not implementation complexity.
participants (5)
-
Beman Dawes -
Darryl Green -
Edward Diener -
Mathias Gaunard -
Scott McMurray