Re: Proposal for Include files/headers

edA-qa wrote:

> Rather than use the old C style of just #include I would recommend a 
> better manner of handling dependencies.

I agree that a more robust mechanism would be a good change. Let's see 
if we can come up with something useful...

> What would be nice is a Java style import system, which makes it easier 
> for new users, and can remove the problem of ordering of dependencies. 

We have to be very careful in trying to adopt something like the Java 
"import" model. The Java approach is very suitable for systems that use 
intermediate language representation (such as byte-codes). In those 
systems, declaration (header) files and implementation files are blended 
into one. But let's be ignorant for a while...

> (The #include system should also remain since it has other uses than 
> resolving dependencies).

I agree that the preprocessing phase is handy. Some enhancements to the 
preprocessor, such as support for recursion, would be useful-- 
generation of boiler plate templates with N-number of parameters would 
be a snap.

> Example:
> 
>     #import Math.Matrix    //get a single definition
>     #import Http    //get entire namespace

Today, the use of the hash sign (#) implies a preprocessor directive. In 
my opinion pulling the class definition out of an enclosing namespace 
surely falls outside of the preprocessor's capabilities.

I suggest, rather than introducing another keyword, to enhance the 
workings of the existing "using" language declaration. Also, I'm not 
particularly fond of the idea that a program source code relies that 
there is even a file-system underneath it. After all, classes, 
namespaces and other scoping constructs don't have to be mapped to 
files-- for example, I can imagine an IDE that uses a kind of 
presistable tree database for storing all the above.

This "using" declaration, instead of implying certain directory 
structure, would make use of a compiler-specific dictionary resource-- 
maybe a file-- that  would provide a mapping between pulled 
namespaces/classes and their physical location in some store. A store 
could be a file system, a database or yet something else that a vendor 
supplies. Now, a source program would only specify what it needs in 
terms of "using" without worrying about circular references or where 
this stuff actually comes from:

// In some resource (could be a file) user declares:

using Math.Matrix;
using Http;

...

A separate resource would provide necessary mapping information; a naive 
example in XML:

<Scope type="namespace">
   <Name>Math</Name>
   <ResourceInfo>
     <StoreType>FileSystem</StoreType>
     <Location>[directory]/Math</Location>
   </ResourceInfo>
   <Scope type="class">
     <Name>Matrix</Name>
   </Scope>
   ...
<Scope>

The advantages are that the compiler can figure out very quickly if 
something is a namespace or a class and where to look for it in the 
store. Source programs would only express their dependencies on language 
entities such as namespaces or classes.

The main disadvance is the maintenance of the "mapping" resource, 
although automation tools can be of great help here.

There is something else I wanted to touch on while on the subject. There 
is a potential for confusion if we allow users to import a single class 
out of its namespace, like in "import Math.Matrix" example. It is 
customary in C++, and presumably will be so in C2, to define certain 
functions outside of the class, yet those functions are still considered 
to be part of that class definition. Consider:

// resource defining Complex:
namespace Math
{
   class Complex
   {
   };

   Complex operator+ (Complex const&& lhs, Complex const&& rhs);
};

// resource using Complex:
import Math.Complex; //get a single definition

Complex c1, c2, c3;
...
c3 = c1 + c2; // error, operator+ for type Complex not defined (huh?)

The user above may not realize that she needs to pull an entire Math 
namespace for the Complex to work properly. This is *not* intuitive. 
Java doesn't have free functions, hence this problem is avoided and in 
C++ we don't "import" individual classes-- we include entire files with 
all the definitions they provide.

--
Slawomir Lisznianski
C2 Language Group Principal (http://c2-lang.org)

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click