On 4/28/2014 4:29 AM, "Ola Fosheim Grøstad"
<[email protected]>" wrote:
This is close. Forgive inaccurate syntax, but I see at least these issues that
will make namespaces/module-system broken in terms of maintenance:
YEAR 2014:
framework1.d:
extern (C++, std){ void something(); }
framework2.d:
extern (C++,std){void something(); void anything();}
application.d:
import framework1;
import framework2;
… std.something(); // is this ok, because the extern signatures match?
No. Even though they are the same function as far as the signatures are
concerned, they are different functions as far as the D type system is
concerned, and hence the call is ambiguous. You'll have to qualify by
framework1.std.something() or framework2.std.something().
std.d is updated:
void something(){}
void coolstuff(){}
application.d is updated to use the new coolstuff():
import framework1;
import framework2;
import.std();
… std.something(); // namespace encapsulation broken or fail?
… std.coolstuff();
No problem, std.d overrides because it is imported directly and so std is in the
current scope. The current scope overrides imported scopes.
application.d is corrected to (or using some other resolution):
import framework1;
import framework2;
import.std();
… framework2.std.something();
… std.coolstuff();
Again, no problem.
YEAR 2016:
framework2.d is modified:
extern (C++,std){ void anything(); }
application.d is recompiled unmodified:
import framework1;
import framework2;
import.std();
// fails even though the signature is still in framework1
… framework2.std.something();
Still no problem. Qualifying it with framework2 says which one you want.
… std.coolstuff();
Remember std is a symbol in the current scope.
Right, but I want to be sure that the type-system sees all externs with the same
signature as the same type.
Remember, a C++ signature is the same as its type in C++, but that is not true
of D.
I also am not sure how the "closing of namespaces"
will work if you have multiple frameworks that independently specify their own
C++ bindings to the same library.
D will regard those namespaces as completely separate and distinct scopes. The
fact that C++ symbols in those separate scopes will mangle to the same symbol is
up to the programmer to deal with - the same as with extern(C) symbols.
The sole purpose of namespace/modules is to have clean separation between
frameworks and support evolutionary development. I am not convinced that this
property is not broken with the proposed change.
To get around this you will have to remove the "closing of namespaces"
restriction and add a root "cpp" so that all cpp namespaces get:
cpp.std.something() etc…
I don't think there's anything needed to be gotten around here.
