On Thursday, 13 August 2015 at 15:49:10 UTC, Dicebot wrote:
On Thursday, 13 August 2015 at 15:40:12 UTC, Timon Gehr wrote:
You know about static imports, right?
Yes, as well as about renamed and selective ones ;)
Problem with static imports is that they are all-or-nothing.
And in our projects it is common to have module names with 5
nested packages or even more. Typing all of it is impractical -
simple prefix gives enough protection from random clashes.
D module system is completely broken in that regard.
What's the alternative?
When doing my old "Rust vs D" comparison I have been mentioning
their import semantics as a big win. When you do import like
this:
use phrases::english::greetings;
You must always also qualify symbol name with module name like
this:
println!("Hello in English: {}", greetings::hello());
And this won't compile:
println!("Hello in English: {}", hello());
It has similar benefits as the idiom proposed in this topic -
greatly reduced risk of accidental clashes.
You can get that behavior with static imports in D, but having to
use the whole import path while referencing symbols gets ugly
fast. There's a reason that using directives get used heavily in
C++, though at least there, if you're behaving yourself and not
using using directives in .h files, that doesn't affect
#includes, unlike with D's import (though having to fully qualify
everything in header files is always annoying). But you still end
up with potential breakage in .cpp files due to new symbols being
introduced which clash.
I honestly don't see a good solution to the problem, because
requiring that you fully qualify symbols is incredibly annoying
and hideous, but if you don't, then adding symbols to a module is
always going to break code. As far as I can tell, your module
system is stuck with one poison or the other. Maybe something
similar to using directives that didn't leak outside of the
module would be a reasonable compromise, but then many folks
would just have a using directive for every import in order to
avoid having to fully qualify symbols. So, I really don't see a
good solution, and while the potential breakage caused by D's
solution is annoying, I'd much rather have that then be forced to
use fully qualified names.
- Jonathan M Davis
