[webkit-dev] type of JSChar
lars at trolltech.com
Fri Jul 27 11:51:20 PDT 2007
> > 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
We are not planning to export this header as part of our public API. If
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
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.
> 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).
More information about the webkit-dev