> On Aug 29, 2017, at 10:15 AM, Darin Adler <da...@apple.com> wrote: > > If we decide that we can’t support file scope identifiers then we should > figure out the most practical way to do it. Of course this affects constants > and variables, too, not just functions. > > I think this special FILENAME namespace isn’t all that helpful or needed. If > a file contains a class like, say, Element, then we can name the namespace > ElementInternals or whatever else seems logical. Calling it FILENAME instead > doesn’t make things more readable nor more foolproof and is also likely to > confuse development tools unnecessarily. Note that we can use “using > namespace” inside functions if needed, but not at the file level.
I’m not particularly opposed to using a different namespace name. Unfortunately, that still doesn’t help with the ElementInternal:: invocation problem since you can’t forward ‘using namespace ElementInternal’ inside the class declaration of Element. > > I think the harder part is how to enforce this rule if the theory is that we > can’t avoid conflicts with ad hoc naming. Using namespaces isn’t fool proof > unless there is something that checks for accidental use of the global scope. I agree that we will need have some tool that prevents things from being placed into the global scope. My plan was to do that after getting the build working, with the belief that the issue would be relatively contained for the brief period between when we get unified builds working and the linter is place. This gets the most value to developers as soon as possible, which seems very valuable. > > I don’t see that universal use of namespaces is required to avoid conflicts. > We manage to keep things unique across the whole project in headers using a > combination of namespaces and naming and I don’t see why it would require > such a firm rule inside source files as long as we clarify the uniqueness > requirement. To be clear, I don’t think it’s required. Many other projects use unified source builds without using namespaces to solve the problem. My primary reasoning for using namespaces is a combination of avoiding the mental cost of thinking about the name collisions and just applying a simple rule. I’d also like to make this easier to understand for WebKit noobies, which is why I thought FILENAME would be simpler to wrap their heads around. > > So I think we should not do the FILENAME thing and we should maybe not even > emphasize mandatory use of namespaces to avoid conflicts. Instead I suggest > we focus on making sure we tools that help us detect conflicts before code is > checked in even before we make the transition to this new way of building. Without the namespace rule, any tool that checks for global namespace collisions won’t be all that useful for regular development. I doubt anyone is going to run such a script before they go to upload a patch to bugzilla. Even if they did it’s not clear that it would help them any more than just trying to compile and fixing the issue after they see the build error. So developers will still hit the name collision issue randomly throughout development. > > — Darin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
