For those new to the party, D eliminates the need for header files. Interface and implementation are all part of the same code unit, called a module. Instead of #including headers, you import modules. Modules can reside in a package hierarchy, much like Java classes. So, given this source file:
// This is the module 'bar' in the package 'foo'.
module foo.bar;
void baz()
{
// Do something.
}
You would use it like this:
module myapp.mymod;
// Import the foo.bar module so its symbols are accessible by this module
import foo.bar;
void myfunc()
{
// baz is visible, so it can be called like this
baz();
// Or, with the fully-qualified name
foo.bar.baz();
}
So yes, a module namespace does exist, but it isn't enforced by default. That means that there can be conflicts if multiple imported modules export functions/types with the same signature. Now, from the user side, it can be enforced two ways. First, is by using static import.
static import foo.bar;
Now, everything you access in the foo.bar module must be prefixed with "foo.bar". You can go one better and add an alias that let's you call foo.bar by another name:
alias foo.bar Foobar;
This allows you to call Foobar.baz(), but it's still foo.bar.baz() that is being enforced under the hood. Remove the static keyword from the import, and baz() will still be accessible by itself. The alias is just an alternative, not an enforced namespace.
The second approach is to use a feature called "named imports", which effectively combines the two steps above, but with enforcement of the given name instead of the module name.
import Foobar = foo.bar;
Now, everything you access in the foo.bar module must be prefixed with "Foobar".
These approaches are all fine, but they put the onus on the user to create his own namespace. As a solution for solving namespace conflicts in client code, I think they're just peachy. In fact, I really like them. But from the perspective of a library designer, I have one major issue with it. I want to wrap my functions in a namespace, so that the client can't have conflicts to begin with and doesn't have to remember to use a named or static import.
Currently, in Dolce, I'm presented with the dilemma of how to handle certain functions that really ought to be free functions. I really don't want to take the C approach with function naming conventions, because it just doesn't mesh with the parts of the library that aren't free functions. On the other hand, I don't want to pollute the global namespace with function names that could easily clash with other libraries or client code. One option is to use static methods in a struct, or a non-instantiable class. But, to me, that just really feels dirty. Plus, every new type you define in a D program adds a TypeInfo instance to the final executable. It's not a lot, but it's just useless bloat for a class that is serving as a namespace hack. It offends my sensibilities, I suppose.
So one more option that I'm considering is having a sort of wrapper module that publicly imports the modules with free functions, giving them a name.
module foo.bar;
public import Bar = foo.realbar;
Imported symbols, by default, are accessible only in the module that imports them. So if module A imports module B, and you then import module A , you can't access B's symbols. However, if module A publicly imports B, then you can access B's symbols just by importing module A. So this enforces the namespace on the client if they import this module. Furthermore, clients will have a choice. They can import foo.bar and get access to the Bar namespace, or they can import foo.realbar and get the free functions, or create their own namespace if they need it. I only see a couple of drawbacks. The only problem I have is deciding if this really improves the situation or not.
Of course, the other option is just not to worry about it. Phobos is full of free functions, after all. Ultimately, my point of view is that I'm creating this library for myself, so whatever makes me happy is the way I'm going. I just have to decide which approach makes me happy.
Hey, not sure if you knew about this already, but you can kind of simulate things if you use static imports and [b]with[/b],
[/quote]
The with statement doesn't help me here. That would be useful if I wanted to simulate the C++ [b]using[/b] statement as a library user.
What I want is to enforce the use of a namespace from the library side. D has no feature that allows that. static imports and named imports all rely on the client to implement.
[quote]And then users would always import [b]dolce.all[/b].[/quote]
Never been a fan of this idiom in D. You'll never see a foo.all module in any of my projects!
[quote]Here's another technique, instead of having one all module you could have separate modules and let the user decide which one to import. So you'd have something like this:[/quote]
Yes, this is what I meant in the last couple of paragraphs. It's the approach I actually settled on and implemented, but only for the modules containing free functions. I thought it would be the right solution, but I'm really not that happy with it. It doesn't actually solve anything. The onus is still on the user. But now, instead of deciding whether or not to use a static/named import, they just decide which module they want to import.
So I've finally decided that it just doesn't matter. I've gotten rid of the wrapper modules. Dolce will have some free functions with no namespaces. If there are any clashes, users can solve it themselves with a static or named import and I won't worry about it.
[quote]
Nice blog to follow btw. Good luck with your project!
[/quote]
Thanks!