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 requirement. 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 webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
