On Tue, Apr 28, 2009 at 4:39 PM, Greg Spencer <gspen...@google.com> wrote:
> 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 :-). FYI - it's a drive format time option on the Mac, so they can be case preserving and case sensitive. TVL > > > 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 -~----------~----~----~----~------~----~------~--~---
