Re: [OT] Re: import

[Nicola Pero]

Ok - I think my answer was nor very precise, but I've done my homeworks
now.

> It does not matter.  This kind of problem is not handled by any
> compiler/language. What if you defined two classes with the same name
> in different files with different path? Whatever the language, you can
> confuse the compiler with links to the same file.  Programming
> languages/compilers don't impose any mapping between objects described
> in the language and files (that would link the language to a given
> file system!).  That's why it's usefull to have higher level
> constructs in the language such as packages, modules, classes,
> whatever.

#import in C/ObjC is *not* such a higher level construct.

#import in C/ObjC *is* defined in terms of files, so in term of the
filesystem.

how do you determine if you've loaded the same file already is the problem
- I think it's not easy to implement this efficiently in a portable way
for different filesystems.

said that, I was trying to remember why the compiler people are so angry
with #import, I'm personally pretty uninterested in the #import vs
#include warfare, and if the compiler people recommend to use #include
rather than #import, I'm happy with that - if you want to use #import
instead, I'm happy with that as well.

The only thing is - yes I wouldn't mind some #preprocessor command which
would replace the #ifndef/#define/#endif trinity and declare more cleanly
a `module name' for the file, and the compiler would never load two files
with the same module name, that would be simpler and cleaner than the
#ifndef/#define/#endif trinity (though equivalent).