Re: #import future (summary and proposed solutions)

["Timothy J. Wood" <tjw at omnigroup dot com>]

On Saturday, January 25, 2003, at 05:50  PM, Peter Barada wrote:
[...]
> What is the problem of #import anyway?
[...]


  I have to second this question.

  In my opinion, #include is the problem, not #import.  Yes, there is 
the tired old saw of some headers needing to be included more than once 
and it being the header file's own decision about whether to allow 
multiple inclusion.

  But, I consider multiple inclusion to (a) be extremely rarely needed 
and (b) almost always be an indicator of poor design.

  Clearly the standard can't be changed today, but hopefully we can 
agree that the goal of tool developers should be to make application 
developer's lives easier -- deprecation of features that  make writing 
headers less onerous (i.e., not having to write stupid header guards) 
is counterproductive.

<aside>
  How do oponents of #import think we are supposed to write header 
guards??  Are we supposed to use this silly pattern?

#ifndef _FILENAME_H
#define _FILENAME_H
...
#endif /* _FILENAME_H*/

  What happens when you get two competing packages with the same file?  
The only logical conclusion I see to this is to do what Microsoft 
Visual C++ does with header guards containing UUIDs like 
'AFX_STDAFX_H__FD67504D_D265_4C7D_9845_56DC0914F5A5__INCLUDED_'.  I 
hope we can all agree that would not be very pleasant.
</aside>

  In the dark ages, #include should have had something like #import's 
semantics and then instead of having to deal with '#pragma once' we'd 
have the VERY occasional '#pragma 
more_than_once_because_i_have_a_weird_design'.

  So, back to Geoffrey Keating's original message:

> 7. The docs for #import are vague about its precise semantics, and the 
> wording is
>    subtly different between Apple's Objective-C docs and cpplib's 
> docs.  The
>    common phrasing is that #import prevents multiple inclusion of "the 
> same
>    file", without elaboration on what "the same" might mean.
  I agree that this is somewhat vague, but I don't think the solution 
is to continue down the path of deprecating #import.

  Instead, as much vagueness as possible should be removed and any 
remaining issues stated clearly.  The main vague point that I see is 
the question of content identity vs. location identiy.  I'd argue that 
it's been strongly implied since the NEXTSTEP days that #import used 
location identity rather than some checksum approach.


> 8. Apple's #import implementation differs from the FSF GCC version.
>    Two significant areas of difference are:
>    a. Apple's implementation considers files to be the same if they 
> have the same
>       filename and inode (but not device) number, while the FSF GCC 
> version
>       considers files to be the same if they are accessed by the same 
> simplified
>       path.
>    b. Apple's implementation won't #import a file if it's been 
> previously
>       #included; FSF GCC will.
> 9. Apple's implementation is known to have failure cases if the name 
> and inode
>    number just happen to match.
> 10. On Darwin, inode numbers are 32 bits, so there's no way they can be
>     permanently consistent when (for instance) NFS-mounting a 
> filesystem with
>     64-bit inode numbers.  Thus, saving them in a file is not a good 
> idea.
  How about doing the following for PCH (and for #import in general):

- Do the normal header search, correctly dealing with case insensitive 
filesystems
- Resolve symlinks in the final file, if any
- Store/compare:
	- Filesystem type (hfs, nfs, etc)
	- Some filesystem identifier (the mount name, network location, or 
heck, just an index into the mount table)
	- The inode, extended to 64 bits
	- The file creation time
- Don't store the file name at all in the PCH or compiler innards for 
#import

  I suppose someone could argue that you could have the same header 
file hard linked with two different names.  If you feel really strongly 
about supporting that, I suppose you could keep the name in the list 
above, but I'd really view this as another of the aberrant cases.  
Since you have to stat the file to get its time stamp anyway, you could 
get the link count and do something special for >1 counts -- my 
'special' behavior would be to emit a warning :)

  You could also argue that someone might unmount and remount a NFS 
partition (or any removable local disk), but unless you can come up 
with a UUID for filesystems, this is always going to be a problem.  
Moving any more towards deprecating #import because of this would just 
result the common case getting harder since there isn't a 100% solution 
to the extremely uncommon cases ("perfect is the enemy of good", "baby 
out with the bath water", etc :)

-tim