[webkit-dev] type of JSChar

[Lars Knoll]

> > 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.

Could you explain what you mean by 'good reason'? 

> > 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 are not planning to export this header as part of our public API. If 
someone want's to use this API together with JavascriptCore he is free to do 
so, but this is not at all related to a Qt port of WebKit.

> 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.

I'd also prefer not having it in there. Still for Qt as a platform, the 
correct typedef is unsigned short.

> >> 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.

To have this usable by plugins it would have to be a cross browser API as well 
as a cross platform one. Are there any efforts on the way in this direction?

> 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.


On Friday 27 July 2007 20:32:32 Darin Adler wrote:
> One last comment that might help.
>
> The idea here is that this is a low level API. Lower level than, say,
> the WebKit API. It's not built on top of the platform APIs like AppKit
> on Mac OS X. The idea is that it's potentially independent of WebKit.
> That's a good argument for having it match the low level platform and
> not be built on top of, say, AppKit or Qt. That extends even to things
> like this type.

If someone want's to use JavascriptCore with this low level API he is free to 
do so.

> I guess the whole wchar_t thing is a snafu, though, because we
> normally would not want a type that is different on different
> platforms. Maybe we should dump the idea of using wchar_t on Windows
> for this.

Yes. If the API is supposed to be cross platform it would make most sense if 
the types are also compatible. wchar_t is unfortunately a pretty unusable 
type for cross platform API's as it is 16bit on Windows and 32bit on Linux.

> We were really following ICU's lead here -- ICU being another low
> level library not built on top of a framework like Qt or AppKit.

I do see that. In Qt, although we have lot's of the same functionality as ICU 
builtin, we chose a different path and used unsigned short on all platforms 
(as it's 16bit on all platforms we support).

Lars