On 2/28/2014 10:21 PM, Dicebot wrote:
D design is based on module as smallest composition unit. If you find
yourself in situation where you want to have two namespaces in a single
module, you should split it into two modules.
Consider this.
enum Foo {...}
interface Bar {}
struct BarManager {
public static {
void initialize();
void terminate();
... more stuff
}
}
This is my use-case. I don't want my users to have to refer to Foo or
Bar with any sort of prefix except to avoid name-clashes. However, I
want to logically group the functions to manage Bars under a single
grouping. I don't need or want a Singleton for it. I could use free
functions, but I use the initialize/terminate idiom a lot. As a user of
my own library, it would be horribly annoying to have to fully qualify
each call. Plus, now and again I have multiple "namespace structs" in a
single module. If I see them as all being closely related, why should I
split them off into different modules?
Putting impetus on caller (named imports) is good here and huge
advantage over C++ way in my opinion. It gives more control over
application naming scheme.
On the other hand, by wrapping my namespaced stuff in structs or
classes, I can have multiple namespaces per module, some things
completely outside the namespace, and the user gets a compiler error
if they don't use it. To me, that's much, much neater.
It simply does not fit with D type system, most importantly with
accessiblity attributes. I'd hate to encounter all that you mention as
"benefits" in some D library I am forced to use.
One of the most annoying things for me in C++ is to see something like
some::ridiculously::long::namespace, that I then have to use on each
type declared in that namespace. That makes me add using statements to
the top of each module, which defeats the purpose in the first place. I
would find it equally annoying in D if every module I imported required
me to use a fully-qualified module name. Luckily, that isn't the case.
We only need to do it do avoid conflicts.
My purpose for using namespaces in this way is twofold: to indicate that
those particular functions serve a collective purpose, and to make give
more meaning to the user code. I don't need to worry about naming
conflicts, thanks to the module system, but I don't see the module as
the smallest unit of organization.
