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
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 ;".
 


 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
 


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.
 


 This man would agree:
 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.


 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


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

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.


 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


 
 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

 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.


 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


 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

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


  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



Good point!
Jun 10 2008
prev sibling 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