Re: Compile time options

[Kazunobu Kuriyama]

Sheldon Gill wrote:

> On Sun, 14 Mar 2004 13:05, you wrote:
>
> > On Mar 10, 2004, at 11:14 PM, Sheldon Gill wrote:
> >
> > > I propose that we separate these "internal behaviour" compile time
> > > options
> > Well. The way I read this proposal, is that these options already exist
> > in the libraries, they just happen to be scattered around and are hard
> > to find. Putting them in one place makes it more obvious what kind of
> > internal design decisions were made.  I'd have to agree that this would
> > be useful in some way.
>
> Yes, that is pretty much the intention. One place with some standards about 
> what/where and how it's used.
Then, some macros defining options are moved to options.h.  Those macros,
which were once defined locally, are now made globally visible from any
headers and modules (if they import or include options.h, of course).

This would give some impact on the arrangement of the source files.
For example, we may need to establish some conventions to avoid possible
namespace conflicts. Also, depending on whether or not options.h is
installed as one of the system headers, the places at which we can import
or include it vary; if not installed at all, only *.m files are permitted
to import options.h. (Perhaps, we need a new document dedicated to
options.h to explain them. Alas, the documentation issue still remains...)

So..., what validates the enhancement of visibility?  IMO, it looks more
than a sort of complement to the "poor" documentation; I feel it adds
something unexpected/superfluous to the arrangement of the source files
unless there's any reasonable verification for it.

Considering the ObjC's limited mechanism for namespace protection,
I think namespace protection is more crucial than the documentation
purpose arrangement.

Regards,
- Kazunobu Kuriyama