Greg Spencer wrote:
> So there's currently no right way to do the conversion, but I still think
> that the FilePath constructor is probably in the best position to inspect
> LC_ALL, etc. and do as close to the right thing as possible. I doubt most
> Linux developers even think about this, and so the chances that they will
> implement anything other than assuming that it's ASCII are slim -- this
> would allow us to at least implement a baseline for them.
Not doing the conversion is kinda the point. Well, it's exactly the point.
(Hi, I'm the author of FilePath.)
If you've got an arbitrary path, it might be encoded in some scheme,
and it might not, and it might contain a mix of encodings. The point
of FilePath is "we know it's a path and we don't necessarily know
anything else." Chromium didn't used to have FilePath. Everything
was a wstring which implied UTF-16/32, and the conversions implied
UTF-8 because we couldn't do anything smarter, and there was all sorts
of potential for messing things up. Not a pretty story. When
FilePath was born, the *Hack methods showed up to give us a way to
transition the old-style wstring APIs to new-style FilePath APIs at
reasonable cut points, instead of having to do everything all at once.
I understand your problem. You're saying "I have user-supplied data
that I want to build a filename from," and "I have this pathname that
I want to display back to the user." I agree that it would be good to
have a way to handle these cases in base. I don't know if FilePath
proper is the right place to do it. If we do it in FilePath, it still
won't really be right. If we had something, it should probably be
made to operate only on single pathname components, and it should be
the caller's responsibility to only deal with user-created names with
this interface.
> 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.
Sounds pretty Pythonic.
FilePath already sort of has some support for this - it does a bunch
of things based on feature macros, mostly so that as I was writing it,
I could test the Windows semantics without having to (shudder) resort
to running on Windows. These could probably be adapted to do what
you're asking.
> 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.
It's also a specification and implementation nightmare. Everyone has
a different idea of what "normalization" means. What's your idea?
> 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 :-).
Again with the normalization. What do you want this stuff for?
What's your idea of how this should work?
Remember: FilePath is specified to be light and to never touch the
disk. If you've got a disk-touching operation, it probably doesn't
belong in FilePath proper.
Mark
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
