Re: #import future (summary and proposed solutions)

[Paul Schlie <schlie at attbi dot com>]

Personally, I don't see how two or more files specified at the source
level, which resolve to having distinctly different absolute symbolic
path/names, should be expected (or relied upon), to be treated as being
the same logically unique file. (Actually one could argue they shouldn't).

(I apologize for my earlier terseness, my poor reaction to a sense of
 things likely becoming blown out of proportion to the issues at hand.)

-paul-

on 1/27/03 8:30 AM, Nicola Pero wrote:
> 
>>> 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.
> 
> Why do you consider hard links irrelevant to the discussion ?
> 
> There are still people around using hard links (I suppose you'd use
> symbolic links instead), even if they are getting rarer.  They're most
> frequent in old-time unix programmers.
> 
> If you ask them, they usually claim some of the following as reasons to
> use hard links instead of sym links - hard links are more portable, hard
> links take up less disk space, hard links are faster to access, ...
> 
> Maybe these reasons are obsolete, maybe they are not.  But if the
> filesystem supports hard links, and there are people using them, it's
> relevant to consider what happens when a header is a hard link to another
> one.
>