sharing code between kjs and khtml
Hello WebKit and KHTML hackers, I have some code I'd like to share between JavaScriptCore and WebCore (and in the KDE version it should probably be shared between kjs and khtml). In particular, I am thinking of the following: * New hashtable template code (HashMap/HashSet). This is more flexible than most other hashtables because it lets you use different hash/equal functions with the same type in different tables, and it is highly tuned for performance. In any case, there are four different hand-rolled hashtable implementations in the JavaScriptCore version of kjs that should really be replaced with this code, and in kjs it's not an option to use stuff like QDict or QHash, even if it were desireable to do so. * Better assert macros. So far we've mostly avoided using our ASSERT macros in JavaScriptCore and in the WebCore khtml directory, however, they are better in a few ways than stock assert(). Most notably, they are set up to crash right in the stack frame where the assertion fails, instead of several frames worth of function calls down. This makes for much better stack traces and saves a lot of time when running under gdb. I can think of three basic options for code sharing: 1) Cut and paste the relevant files, use in both places. This sucks because any fixes or improvements would have to be made in two places, and history shows that people will usually forget to update other copies of the code. 2) Dump in kjs and export for use in khtml, even though this stuff has basically nothing to do with a JavaScript API. 3) Make a new module that both kjs and khtml depend on ("kxmlcore"? "kxmlbase"? something like that...). For WebKit purposes 2 and 3 are basically the same, since even with a new logical module we would dump it in JavaScriptCore along with kjs and pcre to avoid making additional shared libraries. Any thoughts? Regards, Maciej
On Jul 24, 2005, at 6:35 PM, Maciej Stachowiak wrote:
I can think of three basic options for code sharing:
1) Cut and paste the relevant files, use in both places. This sucks because any fixes or improvements would have to be made in two places, and history shows that people will usually forget to update other copies of the code.
2) Dump in kjs and export for use in khtml, even though this stuff has basically nothing to do with a JavaScript API.
3) Make a new module that both kjs and khtml depend on ("kxmlcore"? "kxmlbase"? something like that...).
I like both (2) and (3) and don't have a strong preference between them. But then again I usually agree with Maciej on things, so that's no big surprise. -- Darin
participants (2)
-
Darin Adler
-
Maciej Stachowiak