www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why modules is so strongly limited?

reply imbaFireFenix <gebdiman mail.ru> writes:
Hello my friends!
I'm new user of D language and leaarning how it works.
I'm know C++ and trying Rust, GO and some else and now - D is the 
best language for me

But I'm confused... Many coders was great work and interesting 
features, but modules is so strongly limited!!!

https://dlang.org/spec/module.html
Only one module per file.

but Rust and beta VC++ can multiple file to one module! Why 
implemented this limit?

translation unity? It will be greatly!

But for now for huge project need to do:

~~~ ~~~ ~~~

module M1;

class M1
{
}

~~~ ~~~ ~~~

module M2;

import M1;

public alias M1 = M1.M1;

~~~ ~~~ ~~~

import M2;

int main()
{
     M2.M1 Something;
}

~~~ ~~~ ~~~

Thanks.
Jul 13 2016
next sibling parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Wednesday, 13 July 2016 at 20:58:02 UTC, imbaFireFenix wrote:

 Hello my friends!
 I'm new user of D language and leaarning how it works.
 I'm know C++ and trying Rust, GO and some else and now - D is 
 the best language for me

 But I'm confused... Many coders was great work and interesting 
 features, but modules is so strongly limited!!!

 https://dlang.org/spec/module.html
 Only one module per file.

 but Rust and beta VC++ can multiple file to one module! Why 
 implemented this limit?

 translation unity? It will be greatly!

 But for now for huge project need to do:

 ~~~ ~~~ ~~~

 module M1;

 class M1
 {
 }

 ~~~ ~~~ ~~~

 module M2;

 import M1;

 public alias M1 = M1.M1;

 ~~~ ~~~ ~~~

 import M2;

 int main()
 {
     M2.M1 Something;
 }

 ~~~ ~~~ ~~~

 Thanks.


Hi!

In this cases, the usual way is to make a package, this way:

== in file MP/M1.d ==
module MP.M1;

// some pieces of the work

== in file MP/M2.d ==
module MP.M2;

// other pieces of the work

== in file MP/package.d ==
module MP;
public import MP.M1;
public import MP.M2;

// public import everything

== in file main.d ==
module main;
import MP;

// can access everything, because publicly imported by 
MP/package.d
Jul 13 2016
parent reply imbaFireFenix <gebdiman mail.ru> writes:
 In this cases, the usual way is to make a package, this way:

 == in file MP/M1.d ==
 module MP.M1;

 // some pieces of the work

 == in file MP/M2.d ==
 module MP.M2;

 // other pieces of the work

 == in file MP/package.d ==
 module MP;
 public import MP.M1;
 public import MP.M2;

 // public import everything

 == in file main.d ==
 module main;
 import MP;

 // can access everything, because publicly imported by 
 MP/package.d


Thank but I know this. There is no benefits in code style .

In this case: can't use MP.d file name and does not relieve 
duplicate class name to module subpath...
Every where is limit :(

Whole language based on convenient functionality but in modules 
something is wrong...
I know what strongly 1 file = 1 module is simple for implement 
and not difficult to linking, but few dozen lines will allowed to 
get rid of naming hell
Jul 13 2016
parent imbaFireFenix <gebdiman mail.ru> writes:
but few dozen lines will allowed to get rid of naming hell


I mean in compiler source
Jul 13 2016
prev sibling next sibling parent Lodovico Giaretta <lodovico giaretart.net> writes:
On Wednesday, 13 July 2016 at 20:58:02 UTC, imbaFireFenix wrote:

 Hello my friends!
 I'm new user of D language and leaarning how it works.
 I'm know C++ and trying Rust, GO and some else and now - D is 
 the best language for me

 But I'm confused... Many coders was great work and interesting 
 features, but modules is so strongly limited!!!

 https://dlang.org/spec/module.html
 Only one module per file.

 but Rust and beta VC++ can multiple file to one module! Why 
 implemented this limit?

 translation unity? It will be greatly!

 But for now for huge project need to do:

 ~~~ ~~~ ~~~

 module M1;

 class M1
 {
 }

 ~~~ ~~~ ~~~

 module M2;

 import M1;

 public alias M1 = M1.M1;

 ~~~ ~~~ ~~~

 import M2;

 int main()
 {
     M2.M1 Something;
 }

 ~~~ ~~~ ~~~

 Thanks.


You can do that with package modules:

https://dlang.org/spec/module.html#package-module
Jul 13 2016
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, July 13, 2016 20:58:02 imbaFireFenix via Digitalmars-d wrote:

 Hello my friends!
 I'm new user of D language and leaarning how it works.
 I'm know C++ and trying Rust, GO and some else and now - D is the
 best language for me

 But I'm confused... Many coders was great work and interesting
 features, but modules is so strongly limited!!!

 https://dlang.org/spec/module.html
 Only one module per file.

 but Rust and beta VC++ can multiple file to one module! Why
 implemented this limit?

 translation unity? It will be greatly!


It's cleaner and more straightforward for modules to match up one-to-one
with files and for packages to match up one-to-one with directories. Java
does basically the same thing (though they take it even farther, since they
only allow one, public class per module), and IIRC, a number of other
languages do as well (haskell does from what I recall, and python might; I
don't remember). If we didn't do it that way, then it would be a lot harder
to figure out where all of the code for a given module was, and while some
folks may find it occasionally annoying, most of use have no problem
whatosever with modules being files and packages being directories. Overall,
it works very well.

- Jonathan M Davis
Jul 14 2016
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 14 July 2016 at 09:36:17 UTC, Jonathan M Davis wrote:

 On Wednesday, July 13, 2016 20:58:02 imbaFireFenix via 
 Digitalmars-d wrote:

 If we didn't do it that way, then it would be a lot harder to 
 figure out where all of the code for a given module was,


I think that's really the best argument.
Jul 14 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/14/2016 6:37 AM, jmh530 wrote:

 On Thursday, 14 July 2016 at 09:36:17 UTC, Jonathan M Davis wrote:

 On Wednesday, July 13, 2016 20:58:02 imbaFireFenix via Digitalmars-d wrote:

 If we didn't do it that way, then it would be a lot harder to figure out where
 all of the code for a given module was,


 I think that's really the best argument.


Yup. Just like you wouldn't add more class members in another file.

C++'s ability to have any file add members to a namespace, which other files
may 
or may not see, is a terrible mistake. It makes overloading, for example, not 
humanly checkable at scale.
Jul 14 2016
prev sibling parent reply imbaFireFenix <gebdiman mail.ru> writes:
On Thursday, 14 July 2016 at 09:36:17 UTC, Jonathan M Davis wrote:

 Java does basically the same thing (though they take it even 
 farther, since they only allow one, public class per module), 
 and IIRC, a number of other languages do as well (haskell does 
 from what I recall, and python might; I don't remember


Really! I don't know any people who migrate from namespace to 
module/package system and don't hate this.


 If we didn't do it that way, then it would be a lot harder to 
 figure out where all of the code for a given module was


Sure, more flexibility - more complicated.
But that not impossible...
Or it can be enabled or disabled by compiler pararms...


 while some folks may find it occasionally annoying, most of use 
 have no problem whatosever with modules being files and 
 packages being directories.


Using modules like [namespaces + include] not prohibit using 1 
file == [1 class | 1 module], there is expand possibilities for 
beautifuly implementation.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~


All files in project file - including at compilation, but in code 
- mount only at defined scope point (call for namespace unit or 
using/import whole namespace)

Don't need file or part of module? - Exclude from project.
Jul 15 2016
parent The D dude <thedlangdude gmail.com> writes:
On Friday, 15 July 2016 at 20:49:05 UTC, imbaFireFenix wrote:

 On Thursday, 14 July 2016 at 09:36:17 UTC, Jonathan M Davis 
 wrote:

 Java does basically the same thing (though they take it even 
 farther, since they only allow one, public class per module), 
 and IIRC, a number of other languages do as well (haskell does 
 from what I recall, and python might; I don't remember


 Really! I don't know any people who migrate from namespace to 
 module/package system and don't hate this.


I am sorry, the simple module system in Python was on of the 
reason for its success. You do know that (if you are evil) you 
don't need to obey the module rules in D? As long as you import 
all required files, it won't complain. Of course this isn't 
recommended because the folder/file structure is also easier to 
understand for human beings.


 If we didn't do it that way, then it would be a lot harder to 
 figure out where all of the code for a given module was


 Sure, more flexibility - more complicated.
 But that not impossible...
 Or it can be enabled or disabled by compiler pararms...


 while some folks may find it occasionally annoying, most of 
 use have no problem whatosever with modules being files and 
 packages being directories.


 Using modules like [namespaces + include] not prohibit using 1 
 file == [1 class | 1 module], there is expand possibilities for 
 beautifuly implementation.

 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~


 All files in project file - including at compilation, but in 
 code - mount only at defined scope point (call for namespace 
 unit or using/import whole namespace)

 Don't need file or part of module? - Exclude from project.


o_O - that's the job of a compiler ;-)
Jul 16 2016
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 13 July 2016 at 20:58:02 UTC, imbaFireFenix wrote:

 But for now for huge project need to do


Huge projects are usually organized into packages, only small 
projects can fit in a couple of unorganized files.
Jul 14 2016
prev sibling parent user1234 <user1234 user1234.hu> writes:
On Wednesday, 13 July 2016 at 20:58:02 UTC, imbaFireFenix wrote:

 Why modules is so strongly limited ?


Because this are like that.
Jul 14 2016