Re: NSBundle -initWithPath: warning

[Sheldon Gill]

> > IMHO this is a partial mis-diagnosis of the fault.
> >
> > Consider the code:
> > ----<begin code> ----
> > -<snip>-
> > ---<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.

Agreed.


Regards,
Sheldon