[webkit-dev] type of JSChar

[Darin Adler]

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