Re: Problem with my first app

[Pascal Bourguignon]

> Date: Sun, 14 Oct 2001 15:38:35 -0700
> From: Stan Shebs <shebs@apple.com>
> 
> "Philippe C.D. Robert" wrote:
> > 
> > On Sun, 14 Oct 2001 13:58:25 -0400
> > Jason Clouse <jclouse25@home.com> wrote:
> > 
> > > > - ObjC headers should be #imported, not #included
> > >
> > > To change the subject, why is #import deprecated in gcc?  It
> > > strikes me as odd to support a solution which: (1) breaks with
> > > established practice; (2) is--even if only mildly so--ugly; and
> > > (3) requires more typing :-).  It seems to me that using #import
> > > gives you one less thing to remember to do.
> > 
> > I don't know  - but I know that I dislike it *very much*. Your 3rd
> > point is IMHO even a worse one because it is not only about typing
> > but about having developers to type more ifdefs/defines, that is
> > train them to use them all over the place, very ugly indeed!
> 
> #import is not well-defined, and hard, perhaps even impossible, to
> get right for all OSes and and all filesystems.  The problem is that
> it requires a notion of file identity, so it can know to avoid
> including the "same" file more than once.  But how do you detect
> "same" file?  By name?  No, because of symlink tricks.  By inode?
> Better, but not every filesystem has inodes, and other filesystems
> have inodes that are dynamically assigned as for instance NFS
> mounts and unmounts things.  This is not hypothetical, Apple has
> experienced some mysterious include bugs caused by these kinds of
> effects.  By md5?  Can't check it without reading the whole file,
> not good for performance.  Yes, the md5 could be stored in the
> filesystem, but then we're back to the portability problem.
> 
> The #ifndef/#define strategy requires the programmer to establish
> a single global space of #defines.  It can still fail, for instance
> when mixing packages that have similarly-named include files, but
> at least everything is explicit and well-defined.
> [...]

I never  had any problem  with respect to  files and symlink  with any
high level  language.  Why?   Probably because an  'import Something;'
would not refer to a file named 'Something', but to a first class item
of  the language  named Something  (be  it a  package, a  module or  a
class). Up  to the compiler to  have some documented rules  to map the
'Something' name  to a file  path or any  other mean. This is  not the
concern of the language, and not a problem for the programmer, but for
the compiler and development environment.

Once again, in C there's no notion of file. That's the no brain cpp nd
preprocessor which manipulate  files (#include/#import). Hopefully, in
Objective-C  we  have the  notion  of  class  (@interface ClassName  /
@implementation ClassName). If only it had moved the full step in this
direction  we would  have a  @import ClassName  instead of  relying on
#import "FileName".

What that means in the current  state of affairs is that the developer
has  to take some  care and  manipulate -nostdinc  and -I  options, to
avoid problems when there are unfortunate links.

But you're right,  #import is not well-defined. Instead  of going half
step  backward, let's  just  finish  the step  forward  and define  it
properly. It's not impossible, all high level languages have it right.


-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------