On Friday, 8 January 2016 at 13:50:56 UTC, Walter Bright wrote:
On 1/8/2016 12:11 AM, Jacob Carlborg wrote:
Walter, should "ns.a()" work in the above example?
No:
1. first "ns.a" looks up "ns". Finds it in the current module,
"main.ns".
2. Looks "a" up in "main.ns". "a" is not there. Error.
"a()" works because:
1. Look up "a" in current module. Doesn't find it.
2. Look up "a" in import "foo".
1. doesn't find it. Look in imported scope "foo.ns". finds
it.
3. Look up "a" in import "bar".
1. doesn't find it. Look in imported scope "bar.ns". Doesn't
find it.
Found only one "a" in the imports. We have da winnah!
I think name lookup rules are straightforward in D. I explain
them over and over, for years, and nobody but me understands
them. I find it very frustrating.
Lol, that either tells you that you've got it wrong or that your
just too smart!
How bout this, add compiler functionality where one can
contribute patches to dmd, and then experimentally use them?
If Manu has such capabilities, he could check his "theory" about
quite easily(his code would just work)... at leas then everyone
would know what the real issue is.
As much time that has been wasted arguing over this stuff, the
feature and fix could have been implemented already.
e.g.,
dmd ... -expermental-nsmodule ....
Not that it matters, my own personal logic tells me that
namespace resolution should be consistent with D module name
resolution. To treat all namespaces sort of coming from a global
chunk of symbols just seems wrong. The whole point in the first
place was to get around that. Reverting back to C like scope
resolution for something that was suppose to get away from it
doesn't make sense logically.
Basically there are two choices,
D Namespaces are module bound(moduleA.ns2 is different than
moduleB.ns2) or they are not(moduleA.ns2 is the same as
moduleB.ns2).
How bout this for a solution?
Create a new namespace keyword, _namspace or inline namespace or
whatever, it behaves one way and the other behaves the other
way?? This way, everyone wins!!!! Who cares about people that
"might abuse" something... that's trying to solve a problem that
doesn't exist yet. If people want to shoot themselves in the
foot, let them, they will learn, and like everything else, one
will become deprecated over time, it's nothing new.
It's like trying to prevent people from walking because someone
once fell in a man-hole. 99.9% of people are good at walking.
Punish them for the edge case? Maybe the issue is the man hole
instead?
I imagine it would be easier to write a utility that parses the
C++ code and does some magic to make it work in D than getting D
to support something that it already does differently.