JavaScriptCore merge & binary compatibility

[Peter Kelly]

On Sun, 16 Feb 2003, Harri Porten wrote:

> On Sun, 16 Feb 2003, Peter Kelly wrote:
> 
> > Harri, what are your plans for BIC changes to KJS merged from safari? I 
> > seem to recall you or someone else mentioning a new library version to 
> > distinguish it from the currently-released kjs but I'm not really clear
> > what is supposed to be happening there.
> 
> The latest consensus was to accept breaking BC in libkjs without any
> renaming nor major version number change (don't let anyone outside of this
> list hear this;). The justification is the small number of users -
> possibly 0 outside of kdelibs/kdebase.
> 
> > I'm currently looking at merging some of the code but I'd like to know 
> > what public API's can/can't be merged at this stage & how you think we 
> > should approach this.
> 
> In regards to API changes I'm still a bit more hesitant than just BIC
> changes. The most dramatic one will be the use of Identifier rather than
> UString in the extension API but a fallback virtual function should be
> possible so that old code will keep compiling.
> When it comes to Apple's optimized storage of Numbers I would still like
> to present the approach taken in QSA first. It allows for more types to be
> stored more efficiently without coding any special excemptions.
> 
> What APIs are you thinking of ?

The identifier change was the main one. However, after thinking about it 
some more I believe we can actually get the same benefit without having 
the extra Identifier class. The logic for maintaining a pool of identifier 
names could just as easily live in UString, and we can still keep a set of 
built-in UString objects around for lengthPropertyName and friends.

I also think we can avoid the extra versions of get(), put(), 
hasProperty() and deleteProperty() which take an unsigned propertyName. 
The only place I can see where these are used are in array_object.cpp 
(possibly one or two uses in other files as well). This code could instead 
call a getArrayElement() function or similar (implemented as a top-level 
function, not a member function), which depending on the type of object 
calls either get() or an ArrayInstanceImp-specific method. Since this is 
an internal optimisation we can keep it hidden, and it avoids the need for 
the extra virtual functions in ObjectImp.

I think we should try to maintain binary compatibility if at all possible 
(at least until KDE 4.0), as it's not unlikely that people may wish to 
build apps embedding the interpreter that will run on all KDE 3.x 
versions.  Actually KJSEmbed uses it already, there may be others too. If 
we can go with a BC solution to the Identifier and unsigned propertyName 
changes, this takes us some way towards that.

> 
> Harri.
> 
> _______________________________________________
> Khtml-devel@mail.kde.org
> http://mail.kde.org/mailman/listinfo/khtml-devel
> 

-- 
Peter Kelly
pmk@kde.org