> 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 

> 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

Reply via email to