[haiku-development] Re: RFC: find_directory() API extension

On 11/01/2013 10:35 AM, Axel Dörfler wrote:
On November 1, 2013 at 3:00 AM Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
Trivial C++ versions of the two functions could be added, differing only
in the return parameter -- a BPath*, respectively a BStringList*.

Looks good to me overall, although I really haven't given it that much thought
:-)
Will non-packaged applications only get non-packaged paths this way?

find_paths() is independent of the caller. find_path() should return a non-packaged path, iff codePointer refers to a non-packaged object.

Anyway, the only point I don't like is the suggested C++ API: I would add a
simple class instead (BPathFinder?, or just BPaths) that would allow several
versions of FindPath() where you can omit most of the less often needed
parameters, so that the default use cases (for example, iterating over the
add-on directories) can be done without too many NULL arguments :-)

As an alternative for find_path():

class BPathFinder {
public:
        BPathFinder(const void* codePointer = NULL,
                const char* dependency = NULL);

        status_t FindPath(path_base_directory baseDirectory,
                const char* subPath, uint32 flags,
                BPath& path);
        status_t FindPath(path_base_directory baseDirectory,
                const char* subPath, BPath& path);
        status_t FindPath(path_base_directory baseDirectory,
                BPath& path);
};

Regarding find_paths(), I'm not sure it's worth doing a separate class for it just for getting the paths. The only optional parameters are subPath and flags and I think both will be commonly used.

For convenience I was thinking of a BMergedDirectory initializer or AddDirectories() method that would add paths found this way. It would be nice to have a sub or wrapper class that would also add the node monitoring support often needed.

CU, Ingo


Other related posts: