[webkit-dev] type of JSChar
darin at apple.com
Fri Jul 27 11:25:13 PDT 2007
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
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
More information about the webkit-dev