modules

[FunkyM]

In article <e31q6c$im8$1 at digitaldaemon.com>, Gabe says...
>I don't quite understand the module declaration at the top of source files.
>From the D website, I see that 'Modules have a one-to-one correspondence with
>source files. The module name is the file name with the path and extension
>stripped off.' So, I guess my question is: why bother? If the name of the file
>and the name of the module are the same thing, why are you (in essence) stating
>it twice? (It strikes me as a tad 'header.h'y)

It is easier for the compiler to read the qualified module name from the
statement instead of constructing it from the current "directories". This might
especially turn complicated for the compiler has to deal with multiple include
directories and figuring out the base path.

> Wouldn't it make more sense to have implicit module declarations, as in Java, where 'module std' would represent one directory named 'std' and the name of the file simply IS the name of the module?

You define the fully qualified name in Java indirectly with the import
statements. (Which results in the interpreter acting similar to the way I
described the D compiler works in, just that it has to construct its "module"
names beforehand and resolve things, which is more complicated work than the D
compiler has to do with the module approach)

One defined rule is that writing compilers for D should be easy which is one
reason of avoiding stuff which requires the compiler to do a lot of "resolving
work". Instead it defines a language construct which avoides having to do extra
work.

> Naming the file and then naming the module the same thing inside the file seems a tad, well, redundant.

Partly agree. There is a reason for defining the fully qualified name in the
file. Otherwise how would you define the "root" of your class directory? Adding
a new directory below all others would also implicitly introduce a new package
namespace and thus draw all code using fully qualified names to resolve the
correct module go wrong.

> Also, isn't this why there's the somewhat (from my perspective) hacky 'all.d' declarations in some external
> packages? 

Thats not the reaseon. The reason of the hack "all.d", which I recently had to
learn myself, is that D limits you when it comes to define a modular structure
for your sources and prevents unlimited package levels.

As soon as you target to have more than one package level, which (almost!) no
project in D does use yet, you get a problem.

D defines that a package can not have the same name as a module.

This results in you not being to do this with D:

kernel.cpu
kernel.cpu.arm // kernel.cpu already a module, prevents you from writing a good
structure
..

Instead people tend to do things like this (which seriously can be cried about):

kernel.cpu
kernel.armcpu
..

The D community solution is to use the "all.d" approach which turns this into:

kernel.cpu.all
kernel.cpu.arm // once you introduce sub-packages to arm, you will have to add
arm.all etc..
..

It re-enables you to do unlimited levels why not conflicting with the D language
definitions.

Mind that this introduces additional duplicated (unrequired) package levels:
kernel.cpu.arm.Arm // Arm is a class extending a Cpu class for instance

You can notice that in many of the current D based libraries you find ambigious
stuff like:

std.c.windows.windows
gtk.Window.Window
..

I would say that this behaviour is conflicting with the defined goals of the D
language as it requires a "hack/cheat" instead of offering a proper
self-explained solution delivering an "expected-by-the-coder" behaviour.

> Wouldn't 'module std' and 'import std.*' be more effective solutions,
>simply relying on the compiler and PATH variables to sort out the rest?  
>

Unfortunately its not that easy. Main reason being that the compiler will get
more complicated if multiple source paths are used (Has to have a resolver. It
could be though of if it really adds THAT much overhead vs. the simplification
it introduces from the developer-view).

---

Overall looking at your message, I agree that the module statement is the only
one that gives back an impression that it requires some rethinking if a
different approach might not be better (I vote for it and from the responses I
got from the community a lot of people actually agree).

You should READ the forum thread you posted on dsource.org and it's replies
("FunkyM"):
http://www.dsource.org/forums/viewtopic.php?t=1447&start=0&postdays=0&postorder=asc&highlight=

In the end, it's not a discussion about D language semantics, it's a discussion
about the source organisation architecture of the D compiler and the rule
modulename!=packagename. The D language semantics would work even with different
appraoches (like using namespaces which removes the need for any
file/languageelement mapping need).

For my part, after evaluating the language for use in various commercial
projects it is the only left questionable/weak part of D, in contrast to the
remaining geniously designed semantics which are just so logical that it feels
great.

I am preparing a rather detailed post on the main D newsgroup about this
"issue".

However, I first try to prepare a possible solution, otherwise the request will
probably get unnoticed by Walter or die in "you just want C#/Java but D is not
that" (stupid argument) kind of responses.

I undertand most people as of now are ok with the way it is now, but this is
MAINLY as there is no really big library or project yet in D. Most people are ok
with having C like flat-small libraries and organising their few classes in
stuff like "some.module". More ambitious future goals like .NET-like massive
frameworks would fail with the current module mapping architecture (or need the
hacky "all.d" approach and introduce lots of superficient extra package levels
and avoid a nice API design).

A cross-platform GUI library, as Walter wants to have, should have a clear API
design and this is a thing that prevents me from contributing yet in that
section although I would directly like to.

It turns out to be really complicated to find a new approach/solution to D's
source file handling while maintaining the goals set by the language
definitions.

---

BTW: Gabe, you should visit IRC #D on freenode.net as a couple of people want to
get in contact with you including myself.