[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: KJS API changes
From:       Harri Porten <porten () trolltech ! com>
Date:       2001-10-19 15:43:07
[Download RAW message or body]

On Fri, 19 Oct 2001, Peter Kelly wrote:

We've already discussed most of the issues on IRC. So here's the rest of
my comments:

> I've recently been coding a reworking of the KJS API for KDE 3.0. This
> has involved a number of changes in structure, and as such the new API
> will be source incompatible with the 2.x series. The only code that
> uses KJS that I know of is khtml and kpac, so I do not anticipate this
> being a major inconvenience to other develoeprs out there (if it is,
> let me know!).

I've been contacted by several people (I assume companies) that use the
interpreter. That doesn't mean we can't change anything (the KDE 2.2
version works very well unless you have a browser) but let's keep "public"
API changes to a minimum. Not "public" in the C++ sense of accessibility
(public/private methods or classes) but for the cases of someone writing
extensions.

> - The Global object has also been removed. Each interpreter instance
[...]
>   We could possibly provide another constructor which creates an
>   ObjectImp to use.

Please do so. In 90% of applications the user is not interested in
providing his own global object.

> - The isA() method has been removed (use type() == instead), and the
>   Type num has been reduced to primitive types only - Undefined, Null,
>   Boolean, String, Number, Object, Reference, List and Completion

Can't this stay for compatibility ? Doesn't hurt, no ?

> - The typeInfo struct is also gone. Objects now return a String for
>   their class name.
[....]
> - An equivalent to typeInfo is needed so that classes can be identified
>   using a static pointer rather than a string... this will be mostly
>   useful for testing class types in the internal functions in
>   situations where an application's bindings permit objects named with
>   the same class name as internal types, e.g. "Array"

Why not leave the typeInfo struct then ? I see no other way to support
inheritance checks.

Harri.

[prev in list] [next in list] [prev in thread] [next in thread]