Re: NSPathUtilities Patch - 4 - NSPathUtilities.h

[Sheldon Gill]

On Tue, 20 Apr 2004 17:16, Kazunobu Kuriyama wrote:
> Sheldon Gill wrote:
> > Some changes need to be made to the NSPathUtilities header:
>
> Because every programmer is supposed to write her/his code in such a way
> that it doesn't depend on enums' actual values, I don't think all of the
> proposed changes are necessary at the cost of backwards compatibility.
>
> In fact, some of enum values specified by Apple merely appear
> conventional and
> hence aren't for bitwise operations.  So I think assigning specific
> values to
> enums is superfluous (but enums for bitwise operations).  Adding new
> enums to
> the old ones is enough, isn't it?  (Or Apple recommends a bad C programming
> style?  Perhaps, not.  I guess these enums were once constant macros; when
> the enums took over old #define's, particular values were assigned to
> the former
> for backwards compatibility.  Have you ever experienced anything like that,
> haven't you?  So I don't think we need to take the assignments seriously.)

Actually, my motivation isn't simply to follow Apple.
I went along these lines:

1) we want to maintain compatibility with apple as far as possible
2) we want to enhance functionality where it's both possible and valuable

Apple has defined some directory keys and will continue to add to that set.

GNUstep wants to define additional directory keys so we can use the one 
mechanism to locate places in the hierarchy rather than hard-coding. This is 
sane, logical and beneficial.

How do we allow both to continue in a clean, maintainable manner?

GNUstep additional keys start with GS rather than NS to avoid polluting the 
name space.

 The previous method requires us to interleave Apple and GNUstep definitions 
as we go. That's not nice. By separating the keys in the number space, we can 
add to either set neatly and without impact.

It also gives us two functionality benefits which I feel are valuable.

Firstly, it allows a change in the algorithm for 
NSSearchPathForDirectoriesInDomains to make it O(1) instead of O(n).

Secondly it allows that algorithm change to fix the long standing directory 
order bug in NSSearchPathForDirectoriesInDomains.

So we get a clean, maintainable way to add directory keys which can be looked 
up quickly. The cost is a one time break in backward _binary_ compatibility. 
Not compile time compatibility.

> If assigning particular values to them is so significant, why don't you set
> NSAllDomainsMask to 0x0ffff (cf. the code blow, excerpted from your patch),
> the value of which is specified in the Apple's doc.

I'm aware that Apple's definition of NSAllDomainsMask is 0x0ffff which has 
come down from the times past. However, it's been 0xffffffff in GNUstep since 
inception so I chose to stick with that instead.

The point of moving to an enumeration is to allow the compiler to type check 
more stringently.

> Said that, I'm interested in your project, though.  I'm skeptic with
> GNUstep.sh, too.

Cool. Let's make it go away soon.


Regards,
Sheldon