Some fixes for search paths:

[dumganhar]

1. Adds ‘_originalSearchPaths’ variable, ’getOriginalSearchPaths’ returns the original values set by ‘setSearchPaths’ or ‘addSearchPath’.
2. Adds a getter function ‘getDefaultResourceRootPath’.
3. ‘setDefaultResourceRootPath’ should also update search paths and remove file path cache internally.
4. ‘setSearchPaths’ supports to pass self (_originalSearchPath), could be used in ‘setDefaultResourceRootPath’ to update the final ’_searchPathArray’ for searching full path.
5. ‘addSearchPath’ fix, the default resource root path should be the last element in ‘_searchPathArray’.
6. 'setSearchResolutionsOrder' supports to pass self '_searchResolutionsOrderArray' as parameter.

[minggo]

why need to copy searchResolutionsOrder ?

[dumganhar]

Suppose this invocation:

fileUtils->setSearchResolutionsOrder(_searchResolutionsOrderArray);

_searchResolutionsOrderArray will be cleared before the for loop.
The same situation could happen in setSearchPaths.

[dumganhar]

fileUtils->setSearchResolutionsOrder(fileUtils->getSearchResolutionsOrder());
fileUtils->setSearchPaths(fileUtils->getSearchPaths());

will aways fail.

[minggo]

Yep, you are right. But i think it is better to check it at first like

if (_searchResolutionsOrderArray == searchResolutionsOrder)
    return;

[dumganhar]

For setSearchResolutionsOrders, we could.
But for setSearchPaths, we couldn't.
Because setSearchPaths will update _searchPathArray which will be affected by _defaultResourceRootPath.

[minggo]

Yep, i just mean searchResolutionsOrder.

[dumganhar]

@minggo , updated setSearchResolutionsOrder.

[minggo]

why need _originalSearchPaths

[dumganhar]

FileUtils uses _searchPathArray for searching full path internally.
setSearchPaths will modify _searchPathArray variable, it will be connected by _defaultResourceRootPath.
_originalSearchPaths saves the original parameter setSearchPaths passes in, and getSearchPaths returns _originalSearchPath will be more reasonable than returning _searchPathArray. It's the rule of getter returns what user has set.

If getSearchPaths returns _searchPathArray, you could suppose the following code will always not work.

If current search path is bbb/, ccc/

auto oldDefaultResourceRoot = fileUtils->getDefaultResourceRootPath(); // Suppose it return "" which is an empty string.
auto oldSearchPaths = fileUtils->getSearchPaths(); // oldSearchPaths is : ["bbb/", "ccc/"]
fileUtils->setDefaultResouceRootPath("aaa"); // oldSearchPath is : ["aaa/bbb/", "aaa/ccc"]
// oldSearchPaths will be modified by adding a prefix `aaa` since `_searchPathArray` was modified. 

... ...

// reset resource root
fileUtils->setDefaultResourceRootPath(oldDefaultResourceRoot); 
auto newSearchPath = fileUtils->getSearchPaths(); // newSearchPath is incorrect: ["aaa/bbb", "aaa/ccc"] since it returns `_searchPathArray` which was added by prefix 'aaa'

[dumganhar]

@kpkhxlgy0, any thoughts about this pull request since is inspired by your PR (#11195).

[sbrednikhin]

Adding FileUtils::getOriginalSearchPaths is good thing, but what about people who rely on old resource path order?
Making original search paths last in the list looks strange (and I think might have some additional performance cost).

[balmerdx]

This commit is not good.

1. Break backward compatibility.
2. Strange logic. Why one path go to back?????? Confuse interface.
3. Not add new functionality.

In older code is several variants to implement dumganhar logic without change FileUtils class.

• addSearchPath(..., front=true)
• get/setSearchPaths and change path order.

[dumganhar]

@sbrednikhin, @balmerdx
So the key point is that this line push the default resource path to the end, right?
Yes, I know I broke the compatibility here since I think the search path of default resource should always be at the end. I don't know what kinds of situation you will do in your game. Perhaps, more code snippets and more detail are welcome.

Anyway, if you think I was wrong, feel free to submit a new or better pull request to correct my mistake. Thanks.

[sbrednikhin]

I don't care where default resource path is, actually. My only point is that if you breaking regular code behavior, causing people to fix their code (which must rely on some order of paths), you should have some good reason for that. Not just thinking that it is better.
Since at least some people don't see any obvious reason for that change, you could point on it in comment or something.
This project is open source common code - not your own branch.

[dumganhar]

OK，you're totally right, thanks for reminding me. I will revert that line. I was wrong, I used it as 'my own my private branch', good luck guys, thank you guys.

[sbrednikhin]

Thank you, for understanding. We are very appreciate your work.