Andriy Gapon wrote:
Let me shoot the question first - what is the rationale behind NSSearchPathForDirectoriesInDomains not returning directory name if the directory does not exist ? Esp. so if NSUserDomainMask is used ?
This is the way the function was defined to work a long time ago. In other words, it behaves as specified.
The idea in general terms is that you are asking for a location. If that location doesn't exist, it returns <nil> rather than an exception. The location may not exist because you're running on an old or new version where it doesn't exist anymore. Things change.
Calling code is supposed to know and respect this.
In my opinion what NSSearchPathForDirectoriesInDomains() does now is incorrect. I don't have an opportunity to verify how this function behaves in original NeXTStep or how it behaves in OS X framework, but I think GNUstep behavior is unreasonable. I see two possible ways of improving NSSearchPathForDirectoriesInDomains(): 1. just return the names and let calling code worry if the directories actually exist 2. try to create non-existing directories in the list and only if that fails that remove them from the list I personally am torn between simplicity and elegance of #1 and user-friendliness of #2.
I think you've mis-diagnosed the behaviour problem. It isn't in NSSearchPath() but rather the calling code. Creation of a path isn't and shouldn't be the responsibility of NSSearchPath(). That needs to be handled elsewhere. Generally it is, by the way.
There is some sense in (1) but the question arises: "what do you do when the specified directory doesn't make sense on the current system?" You'd end up needing to handle an exception or error return anyway.
Regards, Sheldon _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev