Re: #import future (summary and proposed solutions)

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

>    I suppose if #import ever goes get removed, it won't be the end of 
> the world.... I'll just have to pester Apple into making Project 
> Builder automatically generate UUID-containing header guards.  I'm sure 
> not interesting it doing it by hand :)

Yes :-)

It's not the end of the world if #import is removed, and Project Builder
might be modified to reduce the annoyance of writing header guards. :-)

So let's remove it! :-)

#import might be slightly better than #include, or might be slightly
worse, but what has it to do with ObjC ?  It should really be a discussion
about C and including files in C; ObjC should simply use whatever device
is used to include files in C.

I love ObjC, and I don't think that using #import or #include makes it a
different language.  I'm not loving ObjC because of #import (I never use
#import btw, and I write a lot of ObjC code).  That's not the point.  
That's not why ObjC is better.  ObjC is better because of its superior OO
support. :-)

It is its superior OO support, and not having or not having a few
autogenerated preprocessor comamnds in your header files, which makes it a
superior language and reduces your development/maintenance time.

So, I'm not sympathetic with crusading for keeping #import in face of the
problems it generates.

I'm absolutely *not* sympathetic with crusading for keeping #import by
masquerading it as if it were something very important for ObjC as a
separate language from C.  It's not.  We don't care.  ObjC would be the
same language without #import.

I don't care about #import or #include, but I want ObjC to be

 - a well-defined language.  If #import is ill-defined, I don't want it
into the language.

 - a language which is easy to implement and to maintain.  If #import is
an implementation/maintenance nightmare as it seems to be, I don't want it
into the language.

 - a language which only adds a few OO bits to standard C.  If C includes
files in a certain way, I don't see why ObjC should include files in a
different way.  IMO ObjC is *not* meant to change basic C features such as
how you include files, but only to add its smalltalk-like OO machinery,
with an easy syntax to access it, on top of C.  That makes sure everything
else works precisely as it does in C, which is a great simplification for
whoever wants to write/maintain an ObjC compiler (GCC included).

If you don't like #include, and prefer #import, you should really ask for
the C language to be changed, or ask for #import as a C extension.

#import has *nothing* to do with ObjC per se.

We should somewhat frankly consider the benefits and costs of having
#import as the official way of including files in ObjC.  The benefits are
- IMO - minimal - you save writing #ifndef/#define/#endif.  The cost looks
like very high (judging by these threads) ... too high for the small
benefits it's generating.

=

I somewhat feel that at the end of the day, if Apple looses interest in
ObjC again (as it did in the past), and ObjC becomes again a somewhat
unknown language, someone will have to take the burden of keeping the FSF
GCC ObjC compiler and run time libraries working.

For the long-term safety and future of the language, I think it's much
better if the language is lightweight and simple and doesn't change
drastically basic stuff inherited/shared with C (for example, how do you
include files), because then it's much easier to maintain the compiler
working, and that way the language might survive happily in less
prosperous periods too.

So I think crusading for #import without considering how little we gain
for such a high cost, is actually more harming than helping the long-term
future of the language, and we would help ObjC a lot more by dropping it.