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?

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?

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.

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

"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 :)

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

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

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

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

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