On 11/12/2012 10:44 AM, Robert O'Callahan wrote:
> On Mon, Nov 12, 2012 at 9:37 AM, Zack Weinberg <za...@panix.com> wrote:
>
>> The scenario I'm concerned with is when a .cpp file does 'using namespace
>> A;' and then goes on to define a bunch of its *own* symbols; later someone
>> adds a symbol to namespace A, and gets an unexpected break possibly miles
>> from their own code. I see *avoiding* this phenomenon as the primary
>> *benefit* of namespaces, and it's totally lost if you do 'using namespace'
>> even in .cpp files.
>
> I've never ever seen that happen, though.
It's happening. We're trying to add a mozilla::Range struct to mfbt that would
lightly encapsulate a pointer and a length, providing assertions whenever you
index into it, extract start or end pointers, and so on. It would have been
simple to add, but SpiderMonkey has a js::ion::Range struct already. And as a
semi-convenience we had this in one place:
namespace js { using namespace mozilla; }
SpiderMonkey currently does |using namespace js;| all over the place, though,
so in Ion code there was suddenly an ambiguity between mozilla::Range and
js::ion::Range -- even for code written inside the ion namespace, I believe.
Ordinarily the "innermost" Range would win, but once you start opening
namespaces, that rule goes out the door.
We ended up removing the nested |using| above and making all SpiderMonkey
headers qualify everything with mozilla::. We use few enough things from
mozilla:: so far that we switched to |using mozilla::RangedPtr| and so on in
.cpp files and didn't think twice. The patch itself was pretty big and
annoying, but at least we won't have these issues in the future.
Concerning the DOM nsDocument case, one possible solution might be to refer to
those symbols with a still-qualified but not fully-qualified name. Type
inference code uses types:: without much pain; Ion code uses ion:: (inside the
js namespace) without much pain, either.
For another data point, WebKit's WTF headers include |using WTF::Vector| and
such at the bottom of them, and I have seen grumbling and/or regrets about this
decision, as it's caused issues with name conflicts with some of Google's gtest
framework.
Jeff
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
