[Development] Micro API review: bool QFileInfo::isNativePath()

[João Abecasis]

Hello everyone,

A while back, to go with the removal of file engines from public API, I
added a new function to QFileInfo [1] and there wasn't consensus on the
naming of this function. I offered to bring the name to the list for
review later and that is now.

    bool QFileInfo::isNativePath() const

The docs read:

    Returns true if the file path can be used directly with native APIs.
    Returns false if the file is otherwise supported by a virtual file
    system inside Qt, such as \l{the Qt Resource System}.

    \bold{Note:} Native paths may still require conversion of path
    separators and character encoding, depending on platform and input
    requirements of the native API.

    \sa QDir::toNativeSeparators(), QFile::encodeName(), filePath(),
    absoluteFilePath(), canonicalFilePath()

So, the intent is that this function lets you know whether the path
could be used with native APIs, so it would be safe to pass it as is to
third-party libraries, tools or otherwise, or if it is part of a virtual
filesystem provided by Qt (currently, only the resource file system).
Similar information was previously offered by QAbstractFileEngine
::LocalDiskFlag, obtained through fileFlags().

As pointed out during the review, one of the issues with calling it a
"native path" is that it is not immediately true: the path you can get
back from QFileInfo may require encoding and directory separator
conversions before it can be used with native APIs.

Personally, I don't think this is a big issue, as anyone using native
APIs needs to understand how to go from QString to
<native-path-representation> and the requirements of the APIs they're
using.

Other suggestions proposed during review:

    a) isLocalFile
    b) isNativeFilesystemPath
    c) isResourcePath
    d) isVirtualPath (with inverted semantics)

I don't like a) because we have no information on the locality of the
filesystem, it could be hosted on a remote server. I feel b) makes it
unnecessarily verbose and doesn't add much to the name (as this is
already in QFileInfo). c) I feel limits future evolution and will force
user code to change if we bring back some sort of virtual file systems
(see earlier revisions of patch [2], below). d) Came a bit late ;-)

Anyway, my opinions are just that, I'd like to hear what others think
and see if we can hash out the better API.

For reference, the change and example usage:

    [1] http://codereview.qt-project.org/15665
    [2] http://codereview.qt-project.org/15234

What say you?

Cheers,


João