Ben Hinkle wrote:

> "Sjoerd van Leent" <svanleent@wanadoo.nl> wrote in message
> news:cin09f$2t4j$1@digitaldaemon.com...
> 
>>Sjoerd van Leent wrote:
>>
>>No this is different, I know it is possible of course. I don't mean
>>this, because you are making submodules for every class, which is just
>>the opposite from what I mean.
>>
>>For example, in Java it is possible to import a package with let's say
>>10 classes. Every class is split up in a file. In D you'll have to write
>>one file containing 10 classes (which becomes very large) or you need to
>>split them up *into other modules*, but that weakens modulair design,
>>and is for large projects a pitfall.
> 
> 
> In D you can have any number of classes per file. The only difference
> between putting two classes in one module and putting two classes in two
> modules in the same package is that private variables are no longer shared
> and that was why Walter introduced package scope. Plus I suppose one has to
> "import" two modules instead of one but that is a trivial difference. I
> don't understand why you feel the need to have one huge file containing lots
> of classes. Are you worrying about people importing only one of the modules
> in the package?
> 
> -Ben
> 
> 
No it is just a design problem. When defining a subsystem (in UML) and different classes belonging to it, I want it to be in the same module, not in different ones. I know it is possible to have a public import (just import without private) but it isn't what I am looking for. I want to make one module with multiple files, with the same properties as a normal module would have.

I know it is possible (just as in C++) to have more classes in one module in a file, but I want to have the same module spread over multiple files (More like Java packages or C++ namespaces).

Regards,
Sjoerd

In article <cipbtp$158g$1@digitaldaemon.com>, Sjoerd van Leent says...
>No it is just a design problem. When defining a subsystem (in UML) and different classes belonging to it, I want it to be in the same module, not in different ones. I know it is possible to have a public import (just import without private) but it isn't what I am looking for. I want to make one module with multiple files, with the same properties as a normal module would have.
>
>I know it is possible (just as in C++) to have more classes in one module in a file, but I want to have the same module spread over multiple files (More like Java packages or C++ namespaces).
>
>Regards,
>Sjoerd

Would it be acceptable to extend the interface pattern to your file layout?

//mymodule.all
import mymodule.foo1
import mymodule.foo2
import mymodule.foo3

Simply use "import mymodule.all;" and foo1, foo2 and foo3 come with it.  This is functionally equivalent to what your asking for (I think anyway) while still keeping your classes spread out across multiple .d files.


- Pragma
[[ Eric Anderton at yahoo dot com ]]

pragma wrote:
> In article <cipbtp$158g$1@digitaldaemon.com>, Sjoerd van Leent says...
> 
>>No it is just a design problem. When defining a subsystem (in UML) and different classes belonging to it, I want it to be in the same module, not in different ones. I know it is possible to have a public import (just import without private) but it isn't what I am looking for. I want to make one module with multiple files, with the same properties as a normal module would have.
>>
>>I know it is possible (just as in C++) to have more classes in one module in a file, but I want to have the same module spread over multiple files (More like Java packages or C++ namespaces).
>>
>>Regards,
>>Sjoerd
> 
> 
> Would it be acceptable to extend the interface pattern to your file layout?
> 
> //mymodule.all
> import mymodule.foo1
> import mymodule.foo2
> import mymodule.foo3
> 
> Simply use "import mymodule.all;" and foo1, foo2 and foo3 come with it.  This is
> functionally equivalent to what your asking for (I think anyway) while still
> keeping your classes spread out across multiple .d files.
> 
> 
> - Pragma
> [[ Eric Anderton at yahoo dot com ]]

Currently it is what I am using right now. But it doesn't make me very happy. Otherwise I have to use a different code convention (such as class names after the module names etc...).
Also I don't want anyone to be able importing a part of the whole, which makes things unreadable (and perhaps undesirable) in large projects.
I only ask to consider/think of an extension to the system. Not that the current one is ultimately bad (even if it was, the rest of D would be a very heavy counterweight), but I think it can be even better.

Before pissing off the complete newsgroup I want to say that the language itself is good in practice (though it is new) and is very easy, or should I say straightforward to learn. Where other languages need thick, heavy manuals, D can be learned with only an Internet-browser and a good set of working brains.

Regards,
Sjoerd

pragma wrote:
 > Would it be acceptable to extend the interface pattern to your file layout?
> 
> //mymodule.all
> import mymodule.foo1
> import mymodule.foo2
> import mymodule.foo3
> 
> Simply use "import mymodule.all;" and foo1, foo2 and foo3 come with it.  This is
> functionally equivalent to what your asking for (I think anyway) while still
> keeping your classes spread out across multiple .d files.

If we could have a change to how module lookup works, I think it would be easier (for users) or more intuitive if you could still do just
#import mymodule;
dmd would look for mymodule, notice that it is a directory, and automatically proceed either including all (non-directory) files inside it, or perhaps this.d as it was suggested before, iirc, which would then include all the public import statements.

 - Ben

Benjamin Herr wrote:
> pragma wrote:
>  > Would it be acceptable to extend the interface pattern to your file layout?
> 
>>
>> //mymodule.all
>> import mymodule.foo1
>> import mymodule.foo2
>> import mymodule.foo3
>>
>> Simply use "import mymodule.all;" and foo1, foo2 and foo3 come with it.  This is
>> functionally equivalent to what your asking for (I think anyway) while still
>> keeping your classes spread out across multiple .d files.
> 
> 
> If we could have a change to how module lookup works, I think it would be easier (for users) or more intuitive if you could still do just
> #import mymodule;
> dmd would look for mymodule, notice that it is a directory, and automatically proceed either including all (non-directory) files inside it, or perhaps this.d as it was suggested before, iirc, which would then include all the public import statements.
> 
>  - Ben

I like the first solution of a Directory lookup, but D then needs to put the directory contents (well, all .d files ofcourse) into one object file. It would solve my problem quite well.

Regards,
Sjoerd