On May 4, 2009, at 7:45 PM, George Staikos wrote:


I really like this and it goes in the direction that I was hoping for as well. Hopefully we can get the WINCE port merged upstream before we make this change. :-)

Some comments I have:

1) In some cases some things apply to more than one OS so we have:
#if OS(x) || OS(y) || OS(z) ...
I think we should use:
#if OS(x,y,z)

I think using the "||" operator is more clear, except perhaps in cases where there is a well-defined OS family, such as the Unix-like family of operating systems, or the Windows family. In that case, the OS family should get is own macro.

1b) WINCE actually includes plenty of WIN but in some cases does things differently. How to make this distinction without lots of && and ||?

Perhaps we need another basic OS macro besides WINCE and WIN, which would refer to only full/desktop versions of Windows. Or maybe WIN should mean desktop Windows, and some new macro could represent the facilities that are common to Windows and Windows CE. Then it's just a matter of using the right ifdefs in the right place.


2) We use PLATFORM(TORCHMOBILE) across multiple OS for things that are not necessarily platform specific but specific to our browsers. I guess this is similar to PLATFORM(CHROMIUM). Honestly I don't like filling the code with these but we all do it, including MAC. MAC tends to win the default right now. I'm not sure how best to handle this yet but I foresee a big mess if we aren't careful.

The idea in my proposal is that catchalls like PLATFORM(CHROMIUM), PLATFORM(MAC) and PLATFORM(TORCHMOBILE) would all be phased out, and replaced with macros that describe specific policy decisions. Anyone could make a PortFoo.h header that makes their preferred set of policy choices, but in the code itself the macros would say how and why something is different, rather than who chose to make it different.

This may take time for ports that made heavy use of catchall macros, since in some cases it may be necessary to reverse-engineer the original intent of a port variation, or it may not even have been clearly thought out why particular things should be different. It took us some time to get rid of the older APPLE_CHANGES macro that we used to apply to almost any change we made.

Again, fully support these changes and perhaps some more too. Just give us a bit of time to find the right way to merge the WINCE stuff in first please!

I wouldn't expect us to start changing things next week, but since generally I've heard support for these changes, I would expect in a month or two at most we'll likely start on deploying them. Most likely we will come up with a system that allows gradual migration. At some point, we'll likely require new code to use new-style macros only and not the old PLATFORM stuff.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to