Re: Proposal for Include files/headers

Slawomir Lisznianski wrote:
> 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, 

I don't like the idea of being file system dependent either.  Though in 
interests of portability you need to define at least one mechanism that 
users of the language have that *must* be provided by all implementations.

Also note that C++ doesn't say the <> system includes need to be files, 
an implementation is also free there to magically define everything they 
should include.

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

Uggh, the world of XML comes to make something simple extremely robust. 
  Since, for the most part, people will be using files to define 
namespaces and classes, I suggest a simpler format which must be 
supported by default:

	namespace MySpace = file( "dir/dir/file.h2" ) {
		class MyClass = file( "dir/dir/file.h2" );
	}

This follows a similar syntax to the language itself so it won't be 
foreign to the programmers.  It also is very flexible and allows room 
for expansion.  It additioanlly paves the way to reflection in the 
language itself... :)

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

In my above syntax this doesn't become unwieldly like the XML format. 
Though IDE tools would be able to quickly generate such files from h2 
file declarations.

> 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:

Here is where my intent differed from users.  I do not intend for 
"import" to move things out of their namespace, that would cause the 
same sort of name clashes that exist in Java.

import Math.Complex;

Complex a;	//failure, cannot find Complex
Math.Complex a;	//okay

import Math.Complex;
using Math.Complex;

Complex a;	//okay, due to using directive

What you are proposing is that "using" does both the "import" and the 
"using" directive.  While this may be convenient it has many pitfalls 
for name clashes, consider first in my syntax:

import SQL.Array;
class Array;

Array a;	//clear, refers to class defined above
SQL.Array b;	//refers to item in SQL

Your syntax:

using SQL.Array;
class Array;

Array a;	//ambiguous, which Array
SQL.Array b;	//refers to item in SQL

In the second example, there is no way to refer to the local class 
Array.  You may wish to use the :: scope operator as in C++, but 
consider if the above is inside a namespace -- the using directive has 
made the class completely ambiguous with no way to resolve it.

--

-- 
edA-qa mort-ora-y
Idea Architect
http://disemia.com/

-------------------------------------------------------
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