[Webkit-unassigned] [Bug 20574] New: bindings need better internal support for binding-object-to-webkit-c++-object mapping

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=20574

           Summary: bindings need better internal support for binding-
                    object-to-webkit-c++-object mapping
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Enhancement
          Priority: P2
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: lkcl at lkcl.net


the addition of the glib bindings to the DOM highlight clearly that
better support is needed for bindings.

you now have three bindings systems, each of which are duplicating
thousands of lines of code to provide, in their own special and
absolutely identical way:

* object type mapping on a per-object per-binding basis, to
  mirror Node::nodeType() onto e.g. GDOM_TYPE_XXX for glib

* object hash-mapping on a per-binding basis, to match unique
  creation of binding-objects onto webkit objects.

* a "wrapper" factory on a per-object-type per-binding basis,
  to actually _create_ the binding-objects of the right type,
  when the binding system doesn't know what type of webkit
  object it's being asked to create.

for the glib bindings, i've cut and paste and global-search-replaced
about _two thousand_ lines of JS wrapper factory and other code,
in order to duplicate the exact same required functionality
line-for-line, concept-for-concept, as can be seen in GDOMBinding.cpp
and GDOMHTMLElementWrapperfactory.cpp

to add support for SVG Document objects will require duplication of and
global-search-replace modification of  another thousand or so lines of code.

it would be very simple to add:

* a templated version of the wrapper factory system

* a per-webkit-object pointer to a "private" wrapper class, which
  can contain a list of binding objects, covered and accessed by
  an enum.

  one single extra pointer is not that much space to save vs the
  _three_ (at the moment) comparatively inefficient and duplicated
  sets of hash-map code, each of which require "safety checks"
  to help deal with bugs (e.g. see addWrapper in JSDOMBindings.cpp)

  those bugs don't _exist_ if you have a pointer to a list of
  binding objects _in_ the webkit class: when the webkit class
  is delete()d the binding objects can be double-checked to be
  non-existent.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.