On Jul 27, 2007, at 11:18 AM, Lars Knoll wrote:
I do understand this for your Windows port. In Qt we try to have the
same types across all platforms. This is also true for our QChar
abstraction that is built on top of an unsigned short. So for us
typedef'ing this to wchar_t is as wrong as unsigned short would be
for your windows port.
I'm sorry we don't see eye to eye on this. In the future there's good
reason for this to be API. It was designed to be cross-platfom API
without any reliance on any particular platform. I'd like to see this
left as a possibility for Windows.
For the Qt port, the 'platform' typedef is an unsigned short. So one
could say that the #ifdef for __BULDING_QT does about the same thing
as the #ifdef (WIN32) for your Windows port.
OK. But would we expect people to define __BULDING_QT when using this
header?
We've gone out of our way to not use the internal definitions like
Platform.h in these headers, designed to be API and in a subdirectory
named "API", and it's strange to have __BUILDING_QT here.
Also, since JSStringRef.h is an API header, it's not good to have
it depend on an project-internal define, so that's another reason
to remove the recent change to JSStringRef.h.
Well, it's not an API header for us. Still it's used internally in
WebKit, so we need to do something with the typedef. Different ports
do sometimes have slightly different goals.
Longer term I'd like to see this as cross-platform API. Even though
you don't see the need for this in your Qt port today, I think you
might in the future, for example if it was used as part of a plug-in
API and we wanted the plug-ins to work in both Qt WebKit on Windows
and the WebKit on Windows that's released with Safari.
Could you think about this a little more and see if you're swayed by
my arguments? Also, please discuss this with Maciej if you have a
chance.
-- Darin
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
