Re: cpplib: Start moving switch handling to front ends

[Nicola Pero <nicola at brainstorm dot co dot uk>]

> >>Heh, we tried that argument with our users, but with literally thousands
> >>of headers assuming #import or #pragma once, both internal and external
> >>to Apple, plus an Objective-C book or two recommending the practice,
> >>the response was, shall we say, "negative".  It was pretty clear they
> >>were going to keep firing compiler folks until they found one who was
> >>willing to un-deprecate #import. 1/2 :-)
> >>
> >>In the users' defense, it must be said that #import has been working
> >>well on a huge amount of code - in the 2 1/2 years that I've been at
> >>Apple, we've seen dozens of ICEs for instance, but no failures of
> >>#import to find the right file.  So it's not surprising that users
> >>wonder why we're trying to fix something that doesn't seem broken.
> >>
> >
> >Understood.
> >
> >Apple's in a different boat from FSF GCC - you are only interested in
> >one platform, and you can make sure that ino/dev comparisons work
> >properly there.  I suppose I could live with a patch to disable that
> >warning for Darwin and Objective C only.  However, you could at least
> >update your own documentation to encourage use of #include and #ifndef
> >wrappers instead.  You could borrow the rationale from cpp.texi
> >(I wrote that text; you have my permission to use it)
> >
> Even the encouragement of change was enough to get me threatened...
> Many longtime NeXT developers believe passionately that #import is
> the right way to go, and some even think that it should have been
> adopted by the C standard instead of #include (it's not like
> #include was mandated on the back of the tablets brought down from
> Sinai, after all).
> 
> That attitude may change - GNUstep had this debate several months
> ago, and decided to switch to #include/#ifndef I think - but I'm
> figuring on having to support #import on Macs for several more
> years.

>From time to time there is this flamewar #include vs #import in the
GNUstep mailing lists, but GNUstep has long been on the side of
#include/#ifndef and all GNUstep library headers are protected against
multiple inclusions.  GNUstep does suggest using #include in all the
documentation which produces.

But - but yes - users with a NeXT/Apple background are strongly in favour
of using #import though, usually protest when you tell them to use
#include, and GNUstep has to automatically disable gcc's warnings against
#import in the make system to prevent strong complains from them if the
compiler annoys them with warnings when they use #import. :-P



I think the opposition to #include raises because users don't like to
write 

#ifndef _FOUNDATION_NSOBJECT_H
#define _FOUNDATION_NSOBJECT_H
...
#endif /* _FOUNDATION_NSOBJECT_H */

in the header file being included, they normally complain that Java has
more high-level constructs to prevent multiple imports of a source file.

I often wondered if by simply replacing these three statements with a new,
higher-level statement at the beginning of file, we wouldn't make users
happy.

Something like (pardon the roughness of my example, details can be fixed,
maybe a #pragma or whatever preprocessor magic, I'm just sketching an
idea)

#header-name Foundation/NSObject.h

only one '#header-name' would be allowed in the file, and it must be the
first non-comment code in the file; when encountering this, the
preprocessor would behave as if the three statements include-protection
triad had been found - that is something like

#ifndef _INCLUDE_NAME_Foundation/NSObject.h_H_
#define _INCLUDE_NAME_Foundation/NSObject.h_H_

at the beginning, and

#endif /* _INCLUDE_NAME_Foundation/NSObject.h_H_ 

at the end of the file (the name of the preprocessor #define is built from
the provided #header-name).

Then, you could #include a file as you do in C, but to protect it against
multiple inclusions, a simple '#header-name' (or whatever preprocessor
directive might be appropriate) in the file to include would be enough
(and still it would be perfectly portable, and have all the benefits of a
traditional #ifnded/#define).

That would look a lot like a high-level construct, you can write it simply
and quickly, and might get the favour of users (even if in practice it
would be not at all different from the existing #include/#ifndef
machinery, just more simple and elegant to write).

It could be used in C as well, but there are many C compilers which
wouldn't support it so I guess it wouldn't be very popular; since the ObjC
compiler is pretty standardly the GCC one for everyone, if anyone agrees
on it and it is added, it would be basically an addition to the standard
language and quite portable.

Just my 2 cents for a way out of an otherwise un-solvable conflict. :-)