[Top][All Lists]

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

Re: NSPathUtilities Patch - 4 - NSPathUtilities.h

From: David Ayers
Subject: Re: NSPathUtilities Patch - 4 - NSPathUtilities.h
Date: Wed, 21 Apr 2004 11:23:41 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

Sheldon Gill wrote:

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.

I think breaking binary compatibility is something we should try to avoid as much as we can. Lots of folks have very extensive GNUstep based projects installed and recompiling them is a real issue. What I think we are missing is some type of semi formalized procedure on how to go about it and communicating this to our users.

I believe the in general we avoid breaking binaray compatibility for minor releases and find some way to mark the places we want to clean up for the next major release, in which we can break binary compatibility. (Note that I think the NSView patches which added instance variables in -gui would by this logic require a major release bump for -gui/-back).

Deciding on /when/ breaking binary compatibility is allowed, is therefore delegated to the "release manager" who can simple announce that the next release will be a major relaese and therefor anyone can grep for the marked codes to do the actual cleanup.


reply via email to

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