[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSBundle -initWithPath: warning

From: Sheldon Gill
Subject: Re: NSBundle -initWithPath: warning
Date: Sat, 02 Apr 2005 11:37:19 +0800
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

IMHO this is a partial mis-diagnosis of the fault.

Consider the code:
----<begin code> ----
---<end code>---

Why is the code checking for an absolute path? It is superfluous and is more likely to cause problems than solve them.

I'm not sure about that ... The NSBundle documentation says this should be a 'full pathname', so it looks like the GNUstep implementation is checking and then trying to be a bit more tolerant than the documentation suggests.
>> Consider 1: If the path isn't absolute it may still work in some
>> cases. In the cases it doesn't work, it'll fail to find the file
>> because the path is incorrect. Just like it'd fail if the path was
>> otherwise incorrect.
> Yep ... so the current code will work in more cases than if the check
> and conversion of relative to absolute path was omitted.  I think that's
> a (minor) win for the code as it is.  However, I think it's also
> arguable that we should be less tolerant and fail in all cases where the
> supplied path is relative ... but only if that's the actual MacOS-X
> behavior.

I've looked over this some more and on this point I still think there is a case. The Foundation docs say it needs a "full path", not "thou shalt specify an absolute path". It also says that any symlinks must be resolvable.

I read it as saying 'use a full path otherwise this may not be able to find your bundle and will return nil'.

I believe we comply with the letter of the docs and maintain compatibility without the check.

Still, it'd be interesting to test behaviour on MacOS.

Later on, it checks that the bundle directory is readable. Why?

Because the NSBundle documentation specifies that the intiialiser must return nil if the directory 'doesn't exist or the user doesn't have access to it'

Yes, it does. My mistake. There were no caveats in the OpenStep spec and I hadn't checked this this particular method in the new Foundation docs.

Generally, we should try to ensure that methods conform to the letter of the Apple documentation AND match the behavior in MacOS-X ... though occasionally the two actually conflict.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]