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 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 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 

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.

— Darin
webkit-dev mailing list

Reply via email to