APPLE_CHANGES, namespace directives

[Darin Adler]

Sorry, guys, I didn't get subscribed to the list.

Here are some comments about some WebCore-related issues:

1) It doesn't seem like those APPLE_CHANGES are a good idea, because we 
don't want ifdefs scattered around the code.

First, a clarification. We put APPLE_CHANGES in around changes that we 
don't think are appropriate for other KHTML clients. That doesn't mean 
we want them merged into the main KHTML source tree with "#if 
APPLE_CHANGES" around them. In the long run, for many of the 
APPLE_CHANGES changes, there may be ways to change KHTML so that we can 
get the right behavior for WebCore in a way that doesn't require ifdefs 
at all. And we may also find that it's practical to leave the main 
KHTML and what's inside WebCore 99.9% the same.

We used APPLE_CHANGES for two main reasons:

     a) to mark off things so it's clear they are WebCore-specific
     b) to make it so we can compile the WebCore version of KHTML in a 
non-WebCore fashion and actually use it in, say, Konqueror to test 
changes; I didn't have a chance to do this recently, but I really 
wanted to do this to see how well, for example, our KJS speed 
improvements worked in a Konqueror context

In JavaScriptCore, I think the situation is different. There are very 
few Apple-specific changes in JavaScriptCore, and I could imagine 
actually checking those in to the real KJS tree and having 
JavaScriptCore and KJS being 100% identical, although we might choose 
some other identifier or identifiers to do the ifdefs other than 
APPLE_CHANGES.

2) Why the change to "namespace DOM {" instead of "using namespace DOM" 
in .cpp files?

We had to make this change in some files because of identifier 
conflicts between identifiers in the DOM namespace and identifiers in 
the global namespace. I can't remember which it identifier was 
off-hand, but I was happy to find this simple way to fix it. Anyone 
with a Mac OS X development machine can just change the file back, 
recompile WebCore and you'll immediately see the compiler error.

The reason the fix makes me happy is that wrapping an entire file of 
code that goes in the DOM namespace in "namespace DOM {" is really more 
straightforward and normal C++ idiom in my opinion. I can't think of 
any reason not to switch to that; maybe there's something I'm missing.

To clarify a bit further, the issue is something like this:

     // in a Mac OS X system header file
     void SendMessage(int x);

     // in a KHTML header file
     namespace DOM {
         void SendMessage(int x);
     }

     // in a KHTML cpp file
     using namespace DOM;
     void SendOneMessage(int x)
     {
         SendMessage(x); // ambiguity
     }

I hope I got this right.

     -- Darin