Re: Any hopes for export ?
Keith H Duggar wrote:
On Jul 30, 10:23? pm, Walter Bright <newshou...@digitalmars.com>
wrote:
Thanks, that's pretty much what I thought. The problem is that
C++ namespaces are not closed, in that later on the namespace's
name space can be added to. I feel this is a serious error in
the design of namespaces, but fixing that would be enormously
easier than implementing exported templates.
Judging from my own experience and looking at "professional"
libraries such as STL, Boost, and many others, it seems that
open namespaces are very useful.
Yes, they are seductively useful. There were a lot of proposals for changes in
the D module system that would have required being able to inject more names
into an existing name space. We killed those proposals with prejudice.
Injecting names into a scope violates about every principle of encapsulation
I've ever heard of. It makes for code that has uncontrollable behavior, in that
in order to understand what it does, you have to look at the *whole project*
rather than just that module. It means your carefully constructed module can be
sabotaged by unrelated modules.
A key element to successful module design is making the meaning of the symbols
in it *independent* of the context that imports it.
The C++ model of #include, extending namespaces, ADL, friends, make for poor
control over encapsulation and modularity. This may not be fixable, as (as you
say) so much code has come to rely on it.
(Note I am using the terms module, import, and namespace rather interchangeably
here.)
However, open/close is not the only problem demonstrated by
my example. In fact the primary problem that I see is how to
enable support for short partially qualified names without
clashes?
That's an excellent question. In D, the degenerate case where the name is unique
among all the modules in scope is the obvious, trivial case. When the names are
not unique, and the overloading is disjoint, it also works. If the overloads are
not disjoint, there is an ambiguity error and qualifying the names becomes
necessary.
There's much more detail on how this works here:
http://www.digitalmars.com/d/2.0/hijack.html
The anti-hijacking design is, as far as I know, unique to D and has been very
successful.
Is the D module and import system close to your view of ideal?
I'm very satisfied with it.
What, if anything, would you change about it?
The order that a module's static constructor runs is controlled by the graph of
how modules import other modules, in a depth-first manner. Trying to figure out
the right thing to do when the graph contains cycles is problematic, though.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]