www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - module vs import

reply hukedonfonix <email goes.here> writes:
I'm having some trouble understanding how module differs from import. As far as
i see it they both pretty much do the exact same thing, ie allow you access to
functions, classes etc. of another .d file. Or am i overlooking something quite
basic and obvious here?
Jun 04 2008
next sibling parent "Saaa" <empty needmail.com> writes:
You import modules with 'import' . A module is a .d file.

You only use the 'module' keyword to name your module.
ie.
module test.main;

import test.error;

..

 I'm having some trouble understanding how module differs from import. As 
 far as i see it they both pretty much do the exact same thing, ie allow 
 you access to functions, classes etc. of another .d file. Or am i 
 overlooking something quite basic and obvious here? 

Jun 04 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
hukedonfonix wrote:
 I'm having some trouble understanding how module differs from import. As far
as i see it they both pretty much do the exact same thing, ie allow you access
to functions, classes etc. of another .d file. Or am i overlooking something
quite basic and obvious here?

The "module" keyword is used to assign a name to your module (which incidentally must coincide with its filename & folder structure) while "import" gives you access to the module with the given name.
Jun 04 2008
next sibling parent reply =?ISO-8859-1?Q?Tomasz_Sowi=f1ski?= <tomeksowi gmail.com> writes:
Robert Fraser Wrote:

 The "module" keyword is used to assign a name to your module (which 
 incidentally must coincide with its filename & folder structure) while 
 "import" gives you access to the module with the given name.

By the way, why do you have to repeat the filename in the file itself? I'm sure there must be some reason, but I can't see it now. Tomek
Jun 08 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Tomasz Sowiński" <tomeksowi gmail.com> wrote in message 
news:g2h5f2$1jnq$1 digitalmars.com...
 Robert Fraser Wrote:

 The "module" keyword is used to assign a name to your module (which
 incidentally must coincide with its filename & folder structure) while
 "import" gives you access to the module with the given name.

By the way, why do you have to repeat the filename in the file itself? I'm sure there must be some reason, but I can't see it now. Tomek

I think it might have to do with making it possible to make D work on filesystems where there is no concept of "directories", such as a database-oriented FS. In such a filesystem, there might not be any way to identify a module other than by doing so inside the module. `select contains(*, "module foo.bar;") from files where extension = "d"`. Though even that wouldn't necessarily work since you'd really have to parse the module since it could be written "module foo . bar ;". But in that case, why is the module declaration optional? It's kind of confusing and to be honest, I'm not sure what purpose the module declaration holds. It would be far more efficient in a DB-oriented FS to instead follow some naming convention for modules, allowing you to select them without looking at their contents. ...now I want to remove module declarations from MiniD :)
Jun 08 2008
next sibling parent reply =?ISO-8859-1?Q?Tomasz_Sowi=f1ski?= <tomeksowi gmail.com> writes:
Jarrett Billingsley Wrote:

 I think it might have to do with making it possible to make D work on 
 filesystems where there is no concept of "directories", such as a 
 database-oriented FS.  In such a filesystem, there might not be any way to 
 identify a module other than by doing so inside the module.  `select 
 contains(*, "module foo.bar;") from files where extension = "d"`.  Though 
 even that wouldn't necessarily work since you'd really have to parse the 
 module since it could be written "module                    foo .     bar 
 ;".

Interesting and sensible this db-oriented filesystem seems to be. Sort of an extension of the emerging tendency of getting rid of hierarchies and managing everything as a bag of objects with attributes. I assume this approach will sooner or later be hyped and the-next-big-thinged but heck... I'm tired of directories because of the maintainance cost and the where-to-put-this-file delays. Do you know of any working solution of this kind? I googled and the only thing I came across was a Slashdot art saying MS strives to put it in the new Windows. Tomek
Jun 08 2008
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Tomasz Sowiński" <tomeksowi gmail.com> wrote in message 
news:g2hhv4$2g9l$1 digitalmars.com...

 Interesting and sensible this db-oriented filesystem seems to be. Sort of 
 an extension of the emerging tendency of getting rid of hierarchies and 
 managing everything as a bag of objects with attributes. I assume this 
 approach will sooner or later be hyped and the-next-big-thinged but 
 heck... I'm tired of directories because of the maintainance cost and the 
 where-to-put-this-file delays.

 Do you know of any working solution of this kind? I googled and the only 
 thing I came across was a Slashdot art saying MS strives to put it in the 
 new Windows.

I'm no filesystems researcher but I'd imagine that if an implementation did exist, it'd probably extremely experimental or a proof of concept. I've certainly never heard of one. They might exist on systems that don't get a lot of publicity like mainframes. I'd be interested to see such a filesystem. IIRC Vista was supposed to have something along the lines of a DB-oriented FS, but that was one of the many, many interesting features that was dropped during development, hence what your googling turned up.
Jun 08 2008
prev sibling parent reply BCS <ao pathlink.com> writes:
Reply to Tomasz,

 Jarrett Billingsley Wrote:
 
 I think it might have to do with making it possible to make D work on
 filesystems where there is no concept of "directories", such as a
 database-oriented FS.  In such a filesystem, there might not be any
 way to identify a module other than by doing so inside the module.
 `select contains(*, "module foo.bar;") from files where extension =
 "d"`.  Though even that wouldn't necessarily work since you'd really
 have to parse the module since it could be written "module
 foo .     bar ;".
 

of an extension of the emerging tendency of getting rid of hierarchies and managing everything as a bag of objects with attributes. I assume this approach will sooner or later be hyped and the-next-big-thinged but heck... I'm tired of directories because of the maintainance cost and the where-to-put-this-file delays. Do you know of any working solution of this kind? I googled and the only thing I came across was a Slashdot art saying MS strives to put it in the new Windows. Tomek

with a good search system like that thing in vista, google desktop or an app a friend of mine wrote*, you don't really need directories much even now. *http://www.espsw.com/
Jun 08 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
BCS wrote:
 with a good search system like that thing in vista, google desktop or an 
 app a friend of mine wrote*, you don't really need directories much even 
 now.

This man would agree: http://forums.thedailywtf.com/forums/t/7593.aspx He's even found new uses for it: "Video is by far the most exciting part of Search. I can video in a book and go directly to a given page and play that back in slow motion. I can video in forum screens."
Jun 08 2008
parent BCS <ao pathlink.com> writes:
Reply to Robert,

 BCS wrote:
 
 with a good search system like that thing in vista, google desktop or
 an app a friend of mine wrote*, you don't really need directories
 much even now.
 

http://forums.thedailywtf.com/forums/t/7593.aspx

I still use directories (and don't see that changing) but more often than not the lookup/access is done through a search system. I don't /need/ dirs the same way I don't /need/ anything higher level than ASM. :-)
Jun 09 2008
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Jarrett Billingsley, el  8 de junio a las 13:54 me escribiste:
 "Tomasz Sowiński" <tomeksowi gmail.com> wrote in message 
 news:g2h5f2$1jnq$1 digitalmars.com...
 Robert Fraser Wrote:

 The "module" keyword is used to assign a name to your module (which
 incidentally must coincide with its filename & folder structure) while
 "import" gives you access to the module with the given name.

By the way, why do you have to repeat the filename in the file itself? I'm sure there must be some reason, but I can't see it now. Tomek

I think it might have to do with making it possible to make D work on filesystems where there is no concept of "directories", such as a database-oriented FS.

You mean *relational* database, right? Because hierarchical filesystems *are* databases (hierarchical databases in fact =). LDAP is another popular example of hierarchical database. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- ASALTAN, GOLPEAN SALVAJEMENTE A ANCIANA Y LE COMEN LA PASTAFROLA. -- CrĆ³nica TV
Jun 08 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Leandro Lucarella" <llucax gmail.com> wrote in message 
news:20080609011323.GA31950 homero.springfield.home...

 You mean *relational* database, right? Because hierarchical filesystems
 *are* databases (hierarchical databases in fact =). LDAP is another
 popular example of hierarchical database.

/me is no database expert.
Jun 08 2008
parent Leandro Lucarella <llucax gmail.com> writes:
Jarrett Billingsley, el  8 de junio a las 21:55 me escribiste:
 "Leandro Lucarella" <llucax gmail.com> wrote in message 
 news:20080609011323.GA31950 homero.springfield.home...
 
 You mean *relational* database, right? Because hierarchical filesystems
 *are* databases (hierarchical databases in fact =). LDAP is another
 popular example of hierarchical database.

/me is no database expert.

http://en.wikipedia.org/wiki/Database#Database_models BTW, I'm not a database expert either, but I find very curious that people don't realize that filesystems are databases when they are probably the older most used database (and for a *lot* of problems, probably the clearer and more efficient =). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- 41% of all people take people with curly hair less seriously
Jun 09 2008
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Tomasz Sowif1ski wrote:

 Robert Fraser Wrote:
 
 The "module" keyword is used to assign a name to your module (which
 incidentally must coincide with its filename & folder structure) while
 "import" gives you access to the module with the given name.

By the way, why do you have to repeat the filename in the file itself? I'm sure there must be some reason, but I can't see it now. Tomek

It is only really omittable if you have no hierarchy. The full module name is used in the symbol name mangling (for instance when compiling an object from a module using the -c switch). When you import the same module using the module name (say foo.bar.Util), your application will only link if the mangling (and module names match). The compiler can't guess the hierarchy specified by the importing code when that code isn't part of the compile. For all-at-once compiling, the compiler probably could get it right. Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jun 08 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Lars Ivar Igesund wrote:
 Tomasz Sowif1ski wrote:
 
 Robert Fraser Wrote:

 The "module" keyword is used to assign a name to your module (which
 incidentally must coincide with its filename & folder structure) while
 "import" gives you access to the module with the given name.

sure there must be some reason, but I can't see it now. Tomek

It is only really omittable if you have no hierarchy. The full module name is used in the symbol name mangling (for instance when compiling an object from a module using the -c switch). When you import the same module using the module name (say foo.bar.Util), your application will only link if the mangling (and module names match). The compiler can't guess the hierarchy specified by the importing code when that code isn't part of the compile. For all-at-once compiling, the compiler probably could get it right. Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango

Personally I think that the current module/package model is broken. the artificial distinction between modules and packages is wrong. if I have a bunch of small classes, should I put them in one module/file or have a different file for each class and group them together in a package/folder? and more importantly, what if I choose to change between having one huge file and having many small ones without changing the logical hierarchy of my code? it makes sense to put a big class in it's own file but then it's name would be Name.Name (since the best name of the module is the same as the contained class). what if I want to separate the logical structure from the physical one on disk (for a practical example - each sub project is handled by a different team and has it's own sub-folder but this structure is different from the structure of the API - Derelict's package structure is a good example of such issues). I usually do not like anything Microsoft does, but I have to admit that their .net separation of physical assemblies on disk from logical structure of the code in namespaces is genius. this is also tied with the C++ model of compilation which D borrows. in C# there are no header files at all, not even auto generated ones like D's .di files. the latest DMD knows how to split obj files when creating a static lib. thus the 1-1 relation between code units and the compiled binary units is already broken. I think this should be taken to the next logical level and the code organization should be separated from the organization on disk. either the algorithm the compiler uses to find symbols needs to change or another flag can be added to the makefile/dsss.conf that directs the compiler to the physical location of symbols it needs (since we all use build tools anyway to compile code) this is similar to a "project" file in a IDE. regarding deployment: Java jars contain a manifest file with metadata, so does .net assemblies. that kind of file can and should be generated by the compiler and it can contain the above mapping of logical modules to physical locations inside the lib archive. this would be much better than the traditional .a files and .so files. --Yigal
Jun 08 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Yigal Chripun wrote:

 Lars Ivar Igesund wrote:
 Tomasz Sowif1ski wrote:
 
 Robert Fraser Wrote:

 The "module" keyword is used to assign a name to your module (which
 incidentally must coincide with its filename & folder structure) while
 "import" gives you access to the module with the given name.

I'm sure there must be some reason, but I can't see it now. Tomek

It is only really omittable if you have no hierarchy. The full module name is used in the symbol name mangling (for instance when compiling an object from a module using the -c switch). When you import the same module using the module name (say foo.bar.Util), your application will only link if the mangling (and module names match). The compiler can't guess the hierarchy specified by the importing code when that code isn't part of the compile. For all-at-once compiling, the compiler probably could get it right. Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango

Personally I think that the current module/package model is broken. the artificial distinction between modules and packages is wrong. if I have a bunch of small classes, should I put them in one module/file or have a different file for each class and group them together in a package/folder? and more importantly, what if I choose to change between having one huge file and having many small ones without changing the logical hierarchy of my code? it makes sense to put a big class in it's own file but then it's name would be Name.Name (since the best name of the module is the same as the contained class). what if I want to separate the logical structure from the physical one on disk (for a practical example - each sub project is handled by a different team and has it's own sub-folder but this structure is different from the structure of the API - Derelict's package structure is a good example of such issues). I usually do not like anything Microsoft does, but I have to admit that their .net separation of physical assemblies on disk from logical structure of the code in namespaces is genius. this is also tied with the C++ model of compilation which D borrows. in C# there are no header files at all, not even auto generated ones like D's .di files. the latest DMD knows how to split obj files when creating a static lib. thus the 1-1 relation between code units and the compiled binary units is already broken. I think this should be taken to the next logical level and the code organization should be separated from the organization on disk. either the algorithm the compiler uses to find symbols needs to change or another flag can be added to the makefile/dsss.conf that directs the compiler to the physical location of symbols it needs (since we all use build tools anyway to compile code) this is similar to a "project" file in a IDE.

This has been discussed before, and I agree that the current situation isn't ideal for refactoring the codebase, and there is also the estetic issue you mention (Name.Name). Dropping the current restrictions would incur more prolems with ambigiuty when resolving the hierarchy. And note that your example about the new DMD feature regarding object files really doesn't compare - they're more akin to split the source for a modules interface into several implementation files, and thus not in conflict with the current module naming scheme. Oh, and there is a difference between "broken" and "not perfect". The current scheme does work, so it can hardly be considered broken. Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jun 09 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Lars Ivar Igesund wrote:
 Yigal Chripun wrote:
 
 Lars Ivar Igesund wrote:
 Tomasz Sowif1ski wrote:

 Robert Fraser Wrote:

 The "module" keyword is used to assign a name to your module (which
 incidentally must coincide with its filename & folder structure) while
 "import" gives you access to the module with the given name.

I'm sure there must be some reason, but I can't see it now. Tomek

name is used in the symbol name mangling (for instance when compiling an object from a module using the -c switch). When you import the same module using the module name (say foo.bar.Util), your application will only link if the mangling (and module names match). The compiler can't guess the hierarchy specified by the importing code when that code isn't part of the compile. For all-at-once compiling, the compiler probably could get it right. Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango

artificial distinction between modules and packages is wrong. if I have a bunch of small classes, should I put them in one module/file or have a different file for each class and group them together in a package/folder? and more importantly, what if I choose to change between having one huge file and having many small ones without changing the logical hierarchy of my code? it makes sense to put a big class in it's own file but then it's name would be Name.Name (since the best name of the module is the same as the contained class). what if I want to separate the logical structure from the physical one on disk (for a practical example - each sub project is handled by a different team and has it's own sub-folder but this structure is different from the structure of the API - Derelict's package structure is a good example of such issues). I usually do not like anything Microsoft does, but I have to admit that their .net separation of physical assemblies on disk from logical structure of the code in namespaces is genius. this is also tied with the C++ model of compilation which D borrows. in C# there are no header files at all, not even auto generated ones like D's .di files. the latest DMD knows how to split obj files when creating a static lib. thus the 1-1 relation between code units and the compiled binary units is already broken. I think this should be taken to the next logical level and the code organization should be separated from the organization on disk. either the algorithm the compiler uses to find symbols needs to change or another flag can be added to the makefile/dsss.conf that directs the compiler to the physical location of symbols it needs (since we all use build tools anyway to compile code) this is similar to a "project" file in a IDE.

This has been discussed before, and I agree that the current situation isn't ideal for refactoring the codebase, and there is also the estetic issue you mention (Name.Name). Dropping the current restrictions would incur more prolems with ambigiuty when resolving the hierarchy. And note that your example about the new DMD feature regarding object files really doesn't compare - they're more akin to split the source for a modules interface into several implementation files, and thus not in conflict with the current module naming scheme. Oh, and there is a difference between "broken" and "not perfect". The current scheme does work, so it can hardly be considered broken. Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango

I don't see any /new/ problems of ambiguity with such a scheme. The compiler will just use two completely separate mechanisms - one for resolving physical locations (i.e. files/directories) and another for resolving the logical hierarchy of symbols. maybe my saying that the current system is broken was too strong, but it definitely is not perfect and has issues. as the saying goes: "good enough is the enemy of perfect" I prefer to side with perfect while others may choose otherwise. I wonder what is Walter's position in this regard. --Yigal
Jun 09 2008
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Yigal Chripun wrote:

 Lars Ivar Igesund wrote:
 
 I don't see any /new/ problems of ambiguity with such a scheme. The
 compiler will just use two completely separate mechanisms - one for
 resolving physical locations (i.e. files/directories) and another for
 resolving the logical hierarchy of symbols.
 
 maybe my saying that the current system is broken was too strong, but it
 definitely is not perfect and has issues. as the saying goes:
 "good enough is the enemy of perfect"
 I prefer to side with perfect while others may choose otherwise. I
 wonder what is Walter's position in this regard.

Personally I think implementing such a scheme would be introducing complexity for a questionable gain - you'd rather use a tool for a major refactoring job in any case, and not depend on language mechanics. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jun 09 2008
prev sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Tomasz Sowiński wrote:
 Robert Fraser Wrote:
 
 The "module" keyword is used to assign a name to your module (which 
 incidentally must coincide with its filename & folder structure) while 
 "import" gives you access to the module with the given name.

By the way, why do you have to repeat the filename in the file itself? I'm sure there must be some reason, but I can't see it now. Tomek

First, the module identifier *must* not coincide with the file path. One case where this is useful, and not mentioned in the other replies (I think), is when a module can have multiple implementations. The module that imports find could be a .di file, for example foobar.di, while the actual implementation .d files could have other file names, for example foobar_win32.d, foobar_linux.d etc, here the module identifier is necessary to mangle symbols correctly. If you're using Makefiles or simple scripts to build your software this is an entirely feasible setup! Of course D has the 'version' keyword for this, but sometimes the code can be very big and seperate files might be more maintainable. I personally prefer switching my editor to another file than scrolling a hundreds of lines to look at the other implementation. Tomas
Jun 10 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Tomas Lindquist Olsen" <tomas famolsen.dk> wrote in message 
news:g2lkaq$18e7$1 digitalmars.com...

 First, the module identifier *must* not coincide with the file path.

English pedantry: "must not" is sort of a set phrase and does not have the same meaning as "does not have to". What you said is something like "it is not possible/legal for the module identifier to coincide with the file path," whereas if "must not" were replaced with "does not have to," it would mean what you expected: "it's not necessary for the module identifier to coincide with the file path." :)
Jun 10 2008
prev sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Tue, 10 Jun 2008 14:17:10 +0400, Tomas Lindquist Olsen  
<tomas famolsen.dk> wrote:

 Tomasz SowiƱski wrote:
 Robert Fraser Wrote:

 The "module" keyword is used to assign a name to your module (which  
 incidentally must coincide with its filename & folder structure) while  
 "import" gives you access to the module with the given name.

I'm sure there must be some reason, but I can't see it now. Tomek

First, the module identifier *must* not coincide with the file path. One case where this is useful, and not mentioned in the other replies (I think), is when a module can have multiple implementations. The module that imports find could be a .di file, for example foobar.di, while the actual implementation .d files could have other file names, for example foobar_win32.d, foobar_linux.d etc, here the module identifier is necessary to mangle symbols correctly. If you're using Makefiles or simple scripts to build your software this is an entirely feasible setup! Of course D has the 'version' keyword for this, but sometimes the code can be very big and seperate files might be more maintainable. I personally prefer switching my editor to another file than scrolling a hundreds of lines to look at the other implementation. Tomas

Good point!
Jun 10 2008