Re: #import future (summary and proposed solutions)

[Paul Schlie <schlie at attbi dot com>]

> In fact, I don't understand how your solution would manage hard links.
>
> If /home/nicola/B.h is a hard link to /home/nicola/A.h (that is, they
> have different names on disk, but they are the same inode/file), then
>
> #import "A.h"
> #import "B.h"
>
> wouldn't work properly, because it would include the file twice (since
> A.h and B.h have different paths on disk), while it should include it
> only once, because they are the same file.

Wow, observing that #importing A.h and B.h also wouldn't work if they
contained duplicate copies of the same file content would be nearly as
profound; and nearly as irrelevant.

All that should be necessary to support the intent of #import, is to
reasonably inhibit the inclusion of a uniquely named file multiple times,
under reasonably typical conditions (i.e. inhibit the multiple inclusion
of files which resolve to the same absolute path and name, where it's the
responsibility of the author of the build environment to establish such
conditions, if #import is desired to behave as expected).

Personally don't see any reason to make a mountain of of a mole hill to
support of a facility which is only presently required for ObjC, which
some apparently feel may have a short life expectancy; but should behave
as expected under reasonably typical, and well definable conditions.

-paul-