Bug 172740

code which implements HashMap in webkit - glib bindings - is here:
http://github.com/lkcl/webkit/tree/16401.master/WebCore/bindings/gdom

Hi.. Since we don't have anything to do with the Python bindings, and since I don't know the people behind them, I am somewhat limited in what I can tell you/do to help you.

First of all, none of that information on other bindings you helpfully provided is of any particular interest, since they all involve the internal API which we simply cannot export as we can't guarantee binary compatibility for it, and hence the python bindings will not be able to use such techniques.

Basically, what the bindings have to do is cast the C++ bindings object to the appropriate type before invoking the method. So if a Node is an Element with XHTML namespace and "img" tagName it can be safely converted to an HTMLImageElement and then its methods can be dispatched. Obviously, string comparisons would be slow and messy, so what I can do is add a typeTag method which will provide a array of enums listing all types that it matches, from most specific to most general (e.g. Tag_HTMLPreElement, Tag_HTMLElement, Tag_Element, Tag_Node, 0). I will do so if the bindings people say that this makes sense and that they will use it.

(In reply to comment #0)
> Version:            (using KDE 3.5.9)
> OS:                Linux
> Installed from:    Unspecified

> HTMLImageElement and then its methods can be dispatched. Obviously, string
> comparisons would be slow and messy, so what I can do is add a typeTag method
> which will provide a array of enums listing all types that it matches, from
> most specific to most general (e.g. Tag_HTMLPreElement, Tag_HTMLElement,
> Tag_Element, Tag_Node, 0).

 webkit's JSbindings, ObjectiveC bindings, and now, also, the glib bindings,
 deploy the technique of "up-casting" based on exactly this: an enum technique.

 if you take a look at GDOMBindings.cpp and also
 GDOMHtmlElementWrapperFactory.cpp you will see that quite literally
 EVERY single object and i do mean every single one is "typecasted" up.

 the use of convenience functions "isHTMLElementNode()" or "isSVGElementNode()"
 are also extensively used, to determine which further function
 should be deployed to further perform yet more and more specific
 typecasting.

 but yes, i've seen some code snippets from uses of KHTML::DOM and yes,
 they're forced to use string comparisons.

 so, whilst it _may not_ be your immediate concern to deploy the technique
 of up-casting, the addition of enums and boolean result functions which
 help determine the objects type _real_ fast would make their lives a
 great deal easier.

http://www.nabble.com/Re%3A-port-of-pyjamas-to-pykde---khtml---issues-and-observations-with-pykde-tt19971326.html

yes an enum is _really_ needed.  a vague attempt has been made, in the ruby bindings (see above) and it's woefully incomplete, and non-optimal at best.

... but he's along the right lines [the ruby bindings maintainer[

http://www.mail-archive.com/pyqt@riverbankcomputing.com/msg15197.html

for follow-up purposes, for anyone wishing to pursue this.

i'll cross-link this bug with a post to the pyqt ml as well.

hi folks,
jim bublitz explains clearly what the problem is, in the posts to riverbankcomputing pyqt list.  he mentions that someone called simon
is now maintaining twine, and it's twine where the problem lies.
has anyone made any progress on this issue?
l.

Dear user,

KHTML (and KJS) was a long time more or less unmaintained and got removed in KF6.

Please migrate to use a QWebEngine based HTML component.

We will do no further fixes or improvements to the KF5 branches of these components beside important security fixes.

For security issues, please see:

https://kde.org/info/security/

Sorry that we did not fix this issue during the life-time of KHTML.

Greetings
Christoph Cullmann