Hi Chromium Developers, I'm working on Google's O3D (http://code.google.com/p/o3d), and we (naturally) share some of Chrome's base classes for our code, including the very useful class FilePath.
However, in using FilePath in the last few months, I've seen that it needs some refinement. I'd like to augment the FilePath class with some things that would make it more generally useful -- it's very nicely set up, but it's missing a few things that make it harder to work with than it needs to be: 1) I'd like to add some explicit routines for converting to/from UTF8 and UTF16. While it's nice (and important) that FilePath uses the platform's native string, we've found that many third party libraries have made other assumptions, where they always expect UTF8 (char) or UTF16 (wchar_t) paths regardless of platform, and converting a FilePath to and from those forms is a platform-dependent exercise which should be centralized into the class (i.e. adding "ToUTF8" and "ToWide" functions to the class, and explicit constructors that take each type). 2) I'd like to make it possible to instantiate a POSIX FilePath object on Windows and a Windows FilePath on POSIX platforms. This is because some libraries (e.g. the zip library, or tar files), use POSIX semantics for their paths even on Windows (I haven't seen a use case for Windows paths on POSIX yet, actually). This would make it possible to use the nice API that FilePath has to manipulate paths appropriately for these other libraries. This could be easily accomplished by having POSIX and Windows versions of FilePath, and then typedef'ing FilePath differently on different platforms to one of these versions. 3) It would be helpful to have real path normalization for each of the platforms (although I know what a testing nightmare that can be). I might try and tackle this if people think it would be beneficial. 4) Make sure we handle case sensitivity vs case preservation correctly. It's unclear to me that FilePath does this correctly on the Mac -- Mac file names are case preserving, but case insensitive, Unix filenames are both (and windows filenames are neither :-). So, is there any resistance to any of the above? Do you have other suggestions that I might take into account? Am I violating any design assumptions of FilePath? For #2, is speed/size enough of a concern to avoid a virtual base class (I wouldn't think so, but you never know..)? -Greg. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---