On Sat, Mar 23, 2013 at 12:36 PM, Yakov Galka
On Sat, Mar 23, 2013 at 2:42 PM, Joseph Van Riper < fleeb.fantastique@gmail.com> wrote:
[...]
As such, it feels to me like a more natural way to work with the file
system is through an object that represents trees, and functions that help
you work with the tree, or represent a particular path on the tree as a generic string, with a particular separator character (or characters).
What are the separator characters in c:\x.txt, c:x.txt, or SYS$SYSDEVICE:[USER.DOCS]PHOTO.JPG:8?
* C:\x.txt: : for root, \ for branches (and branches between leaves). * C:x.txt: : for root, leading right into a leaf that would be wherever your sense of 'current directory' should be. If someone entered this, you'd want to expand this to something like C:\my\current\folder\x.txt before working with it, unless you want a sense of 'current folder'. But that raises an interesting point I hadn't really considered... paths identified by a name, like Windows' %WINDOW% folder, etc. I don't know how often other operating systems use specialized folders that identify to a particular name, but Windows has several folder locations that one might identify with a particular name, even beyond expanding an environment variable (e.g. the Program Files folder). Yeah, this case requires some thought. * SYS$SYSDEVICE:[USER.DOCS]PHOTO.JPG:8: : for root, . for folders, with [] characters surrounding the branches, showing the leaves. In VMS, the leaf has an added attribute (I never discussed the attributes of a leaf) of a revision in addition to an extension, which makes that file system a tad more unique. Good ol' VMS. At the end of the day, in at least two of the three cases, the representation of the path is unique to the system they're on, and could be treated with functions specific to those representations. I'm suggesting, I suppose, a separation between its string representation for a path, and how the path is organized in memory. This could make it possible to create a VMS-style string representation of a Windows file system path, as silly as that might seem.
I claim that the "paths are strings" mindset is too simplistic, narrow minded and useless for defining path arithmetic. It is still true that we *do* want to represent paths as strings, and actually a library that would work with std::strings has its own right for existence. However, any paths library shall not have the word "separator" in its documentation for anything other than the platform specific parts.
I agree with this. The underlying representation should be more sophisticated. But we still need a representation for a particular path as a string, or such a library isn't very useful for most cases. Manipulate a path as if it were something other than a string, and when you've finished manipulating it, call a function to expand it into a string (perhaps for use in an API that depends upon such a string, or for storage, or whatever). With that approach, you could also represent the Windows registry using the
same objects (just a different backend to handle the obviously different API calls). Or SMNP OIDs. Or a web site's paths.
Not really, the syntax is different.
I'm not sure I see what you mean here. Perhaps I didn't express my thoughts well. That wouldn't be a surprise, since I was writing with brevity in mind and not clarity. I'm observing that the operating system provides an API that allow you to traverse a file system in a manner like working with a tree (or forest if you prefer). Similarly, the Windows operating system provides an API that allows you to traverse the registry in a manner like working with a tree. You can go to a parent, you have base nodes, and you have branches and leaves (just with different names... a file in the file system is analogous to a registry item in the registry). I'm observing that several systems seem to use this paradigm, and there's a utility in abstracting it. Interestingly, you can represent a particular path in a file system using a string, and you can represent a particular path in the Windows registry using a string. Note that I mean the path to the item, and not the item itself... obviously you'd need more than a string to represent a particular file within the file system, heh. I think for many use cases where the aforementioned paradigm is used, a string representation for a specific node within the system also exists. If you build individual libraries that map a file system's API to a library's API (a bridge between the two, if you will), you could build a library with eligible library backends that abstract the system API calls to make them common. And you could build a library that takes the underlying tree-like path object and represent it as a string in some format. So, let's say we had a library with a kind of generic path object with a function 'branches()'. That function could return a set of paths that represent other branches found within that particular path object (if any... yes, it should be possible for the path you have to not exist, in which case perhaps it could be created, but you can't find branches or leaves). So, if the path represented a file system path, you'd see other folders. If it represented a key in the Windows registry, it would show other keys. Now, if you wanted to take a particular path object and represent it as a string, you might call a function that takes the path as an argument, and it spits out a string representation of that path that is unique to how that function builds strings from paths. So, it could represent the path with the posix-style forward-slash separator, or the VMS-style root:[folder]file format, or even something else like a root:folder.folder.file format. Since the function that builds strings is simply calling an established set of functions within the generic 'path' like object, it can do this regardless of whether the path represents a Windows file system, windows registry, VMS file system, or an SNMP OID. This is what I wanted to suggest. - Trey