This is an idea that would allow modules to span multiple files. In
foo/bat.d source file, use:
   export module foo.bar;
and foo/bat.d will continue the module foo.bar.

The actual foo.bar module will have to (public) import this file to make it
accessible, or specify them in its module list like:
   module foo.bar, foo.bat, foo.etc;
or
   module foo.bar: foo.bat, foo.etc;

If any other module tries to import foo.bat, it will get an error message
something like:
   Cannot import foo.bat, import foo.bar instead.

foo/bat.d automatically gets the symbols of foo.bar as if it was imported, and has access to its private parts; exactly like it was the same file.

Perhaps export isn't the best word to use, but I figured import/export sound
good together. Maybe it could be:
   continue module foo.bar;
:)

--
Christopher E. Miller

"Vathix" <vathixSpamFix@dprogramming.com> wrote in message news:c8mmgp$2ep6$1@digitaldaemon.com...
> This is an idea that would allow modules to span multiple files. In
> foo/bat.d source file, use:
>    export module foo.bar;
> and foo/bat.d will continue the module foo.bar.
>
> The actual foo.bar module will have to (public) import this file to make
it
> accessible, or specify them in its module list like:
>    module foo.bar, foo.bat, foo.etc;
> or
>    module foo.bar: foo.bat, foo.etc;
>
> If any other module tries to import foo.bat, it will get an error message
> something like:
>    Cannot import foo.bat, import foo.bar instead.
>
> foo/bat.d automatically gets the symbols of foo.bar as if it was imported, and has access to its private parts; exactly like it was the same file.
>
> Perhaps export isn't the best word to use, but I figured import/export
sound
> good together. Maybe it could be:
>    continue module foo.bar;
> :)
>
> --
> Christopher E. Miller
>
>

Good idea. Unfortunately, the module/multiple file problem will not go away anytime soon.

In article <c8nkvp$rvi$1@digitaldaemon.com>, Achilleas Margaritis says...

>Good idea. Unfortunately, the module/multiple file problem will not go away anytime soon.

Last time I posted this, nobody commented, so I'll post this again. I *THINK* we can _already_ do multiple files per module, if my theory is correct. Here's the plan:

---------------------------------------------------------------------
Title: Re: 'Package' access attribute is needed.
Author: Arcane Jill <Arcane_member@pathlink.com>
Date: Thu, 20 May 2004 23:28:29 +0000 (UTC)

Problem solved, I think. I haven't actually tried this, but I don't see any reason why it shouldn't work. Here's how you do it.

Suppose you wish to have four separate source files, which we shall call call john.d, paul.d, george.d and ringo.d.

You also wish that each of these source files should be able to access private data in each of the other source files, so that the collection of source files forms a single module, which we shall call beatles.

Easy peasy.

The content of john.d becomes:

>       module john;
>
>       template TJohn
>       {
>           public
>           {
>               // public declarations
>           }
>
>           private
>           {
>               // package-level declarations
>           }
>       }

That is, you wrap the WHOLE FILE inside a parameterless template declaration, and remove any import statements. The content of paul.d, george.d and ringo.d are similarly wrapped in a template declaration.

Finally, you create one extra source file for the package as a whole - beatles.d - whose content is as follows:

>       module beatles;
>
>       // imports required by ANY of the other source files go here
>
>       import john;
>       import paul;
>       import george;
>       import ringo;
>
>       mixin TJohn;
>       mixin TPaul;
>       mixin TGeorge;
>       mixin TRingo;

I think that should do the trick.

Arcane Jill

Arcane Jill wrote:

> Last time I posted this, nobody commented, so I'll post this again. I *THINK* we can _already_ do multiple files per module, if my theory is correct. Here's the plan:
> 
....
> 
> I think that should do the trick.

That "trick" really looks like trying very hard to press some way of modularization onto D. If you can split a module into file so cleanly, you should really consider to split it into separate modules right from the beginning.

If I understand the specs (http://www.digitalmars.com/d/module.html)
correctly:

--------------------------------------
If the import is private, such as:
        module abc;
        private import def;

then def is not searched when another module imports abc.
--------------------------------------

then a normal import will already reexport all the imported symbols. (This should perhaps be documented more clearly?)

If a module grows too large for one file, you should just try to split out parts of it into different modules and import those.

In article <c8s75j$18u0$1@digitaldaemon.com>, Norbert Nemec says...

>That "trick" really looks like trying very hard to press some way of modularization onto D. If you can split a module into file so cleanly, you should really consider to split it into separate modules right from the beginning.

For the record, it was not I who wanted such a split - I merely proposed a way of doing it. My own project do not require, nor use, this trick.

In effect, I'm using suggesting mixin as a poor person's #include. That is, instead of:

>       #include "otherfile.c"

we can write:

>       import otherfile;
>       mixin TOtherFile;

providing that the contents of otherfile.d are wrapped inside template TOtherFile.

But I didn't know about private imports. Thanks for bringing that one to my attention. Sounds like a good way to achieve something similar.

Arcane Jill

In article <c8s8ct$1ci3$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <c8s75j$18u0$1@digitaldaemon.com>, Norbert Nemec says...
>
>>That "trick" really looks like trying very hard to press some way of modularization onto D. If you can split a module into file so cleanly, you should really consider to split it into separate modules right from the beginning.
>
>For the record, it was not I who wanted such a split - I merely proposed a way of doing it. My own project do not require, nor use, this trick.
>
>In effect, I'm using suggesting mixin as a poor person's #include. That is, instead of:
>
>>       #include "otherfile.c"
>
>we can write:
>
>>       import otherfile;
>>       mixin TOtherFile;
>
>providing that the contents of otherfile.d are wrapped inside template TOtherFile.
>
>But I didn't know about private imports. Thanks for bringing that one to my attention. Sounds like a good way to achieve something similar.
>
>Arcane Jill
>
>

All the above posts lead me to one thought: multiple file/module needs direct support from the language.

When every programmer offers his/her own version of a solution to the same problem, leading to various incompatibilities between libraries, then it is time for the language designer to take notice and solve the problem cleanly through a language modification/addition.

It's like C++ and strings: every library has its own version.

Achilleas Margaritis wrote:

> All the above posts lead me to one thought: multiple file/module needs direct support from the language.

What would it be needed for? Just split your file in whatever way you like and import all parts into one module which is then offered for import in programs etc.

The feature that might be interesting would be "friend" modules (which would be mostly similar to the recent proposal of package-private items.)

> When every programmer offers his/her own version of a solution to the same problem, leading to various incompatibilities between libraries, then it is time for the language designer to take notice and solve the problem cleanly through a language modification/addition.

If there is a clean solution possible with the current features of the language, it is just as good to promote that solution for general use.

> It's like C++ and strings: every library has its own version.

That's because C++ itself did not offer a clean solution for strings in the beginning. (basic_string just came too late)

Norbert Nemec wrote:
> Achilleas Margaritis wrote:
> 
> 
>>All the above posts lead me to one thought: multiple file/module needs
>>direct support from the language.
> 
> 
> What would it be needed for? Just split your file in whatever way you like
> and import all parts into one module which is then offered for import in
> programs etc.
> 
> The feature that might be interesting would be "friend" modules (which would
> be mostly similar to the recent proposal of package-private items.)

That is the whole point, of the discussion (at least for me): the need for "friend" code to be in the same module, hence in the same file. This just isn't practical.

It may look like a minor annoyance, but in everyday live this means that big projects will have to make all the "friend" stuff public, even if that is dangerous and allows misuse. The other alternative, having huge files with tens of thousands of lines of code, would be a major problem in a multi-programmer environment.

But I'm repeating myself...

I wish Walter would comment on this. Not having any feedback on whether he at least acknowledges the problem to exist is quite frustrating.

Hauke

>It may look like a minor annoyance, but in everyday live this means that big projects will have to make all the "friend" stuff public, even if that is dangerous and allows misuse. The other alternative, having huge files with tens of thousands of lines of code, would be a major problem in a multi-programmer environment.

Or you could just try my sugguestion.


>But I'm repeating myself...

But I'm repeating myself


>I wish Walter would comment on this. Not having any feedback on whether he at least acknowledges the problem to exist is quite frustrating.

The problem doesn't exist because mixins already solve it. The language can already do what you want.

Don't you see? The statements:

>       mixin TStuffFromFile1
>       mixin TStuffFromFile2

can achieve the same thing as #include in C. If the thing you are including contains stuff wrapped in the private attribute, then it becomes private in the including file. That is, the including file effectively becomes the concatenation of the included files. In other words - the compiler SEES one big file, in which the notion of private is spread across the whole of that conceptual file (so anything declared private in one file will be visible to any other similarly included file) - but you WRITE many files, which can be version-controlled separatly.

When Walter invented mixins, he also solved this problem.

This is a powerful language feature, and I'm not sure that its full power has been fully appreciated.

Arcane Jill

Arcane Jill wrote:
>>It may look like a minor annoyance, but in everyday live this means that big projects will have to make all the "friend" stuff public, even if that is dangerous and allows misuse. The other alternative, having huge files with tens of thousands of lines of code, would be a major problem in a multi-programmer environment.
> 
>>I wish Walter would comment on this. Not having any feedback on whether he at least acknowledges the problem to exist is quite frustrating.
> 
> 
> The problem doesn't exist because mixins already solve it. The language can
> already do what you want.

Not really. Don't take this personally, but I see the mixin workaround as an ugly hack. It is neither convenient when you write the code nor is it easy to understand what the writer intended when you read it.

Also, putting all code in a template just to improve "importability" makes red lights go off everywhere in my head. I suspect that it might increase compile time, it might obfuscate compiling error messages and it might make it difficult for the debugger to display the code that is currently executed. It will also confuse documentation programs like doxygen and may have a similar effect on some class tree parsers in IDEs.

It is nice that mixins are powerful enough to make a hack possible, but IMHO using this hack regularly is a bad idea.

Hauke