[webkit-reviews] review requested: [Bug 16401] [GTK] GObject/C DOM binding : [Attachment 32633] brings glib/gobject bindings up to svn r44473.

[bugzilla-daemon at webkit.org]

Luke Kenneth Casson Leighton <lkcl at lkcl.net> has asked	for review:
Bug 16401: [GTK] GObject/C DOM binding
https://bugs.webkit.org/show_bug.cgi?id=16401

Attachment 32633: brings glib/gobject bindings up to svn r44473.
https://bugs.webkit.org/attachment.cgi?id=32633&action=review

------- Additional Comments from Luke Kenneth Casson Leighton <lkcl at lkcl.net>
okaay, this is the "2 steps backwards, 1 step forwards" patch which, as
explained, cannot take into consideration adam's fantastic work because it was
impossible for me to follow it.  even _one_ feature removed (and the first that
adam picked was event handling) meant that the test framework (pyjamas 
desktop) was totally cut off at the knees.

dave agrees - https://bugs.webkit.org/show_bug.cgi?id=16401#c214 - that the way
forward is to take this "as-is" and then to move forward from there.  over what
is likely to be a period of several months, retro-fix issues that have been
raised and recorded will - should - be created.  it would have been nice if
people had listened to my advice on this months ago, but, not believing me, you
had to find out for yourselves [by taking up adam's time as well as mine].  at
least we're moving forward, now, rather than playing silly buggers.

i'll be _more_ than happy to help review individual small dedicated controlled
manageable single-purpose patches that anyone cares to contribute: perhaps by
comparing the differences between what adam has done and what this patch
provides it may make individuals' lives easier when it comes to updating this
strategically critical area of functionality.

there is a _lot_ still left to be done - but, butbutbut, what is here is
_provably_ working.  it would be very nice if it stayed that way, and that
pyjamas-desktop, the only current project which utilised these bindings with
near 100% code coverage, carried on working.

still on the critical TODO list, after this patch is accepted (let alone any
bug-fixes / coding-standards / review update work!) is: Enums, SVG 2D Canvas,
and Exception handling.

this latter is proving tiresome to not have, in pywebkitgtk (and
pyjamas-desktop): several bugs could not be found in pyjamas-desktop until
python-xpcom / XULRunner was added as an alternative back-end peer [to
pywebkitgtk].  up until then, due to the lack of error reporting from runtime
exceptions, style attributes and a few others just... silently vanished
(fortunately with no useability impact, but that was down to luck).

as requested, i've made review comments to
https://bugs.webkit.org/show_bug.cgi?id=16401#c191 and
https://bugs.webkit.org/show_bug.cgi?id=16401#c194  - the coding-standards
issues i immediately fixed (as they're dead-easy) however there were issues
raised that should have been raised eight months ago, when i had a complete map
of the code and a handle on the 600+ auto-generated files in my head.  i've
answered them as best i can: now it's time to move on.

one thing that can be seen from this patch: it includes LANGUAGE_GOBJECT as a
#define.  this is in for two separate reasons:

1) until someone can show me how to get a TextDocument object, in order to pass
it to XMLHttpRequest.open(), for that reason and for that sole reason alone,
LANGUAGE_GOBJECT is _absolutely_ required, in order to reactivate
open(DOMString).  otherwise, it's simply not possible to get XMLHttpRequest to
work, and XMLHttpRequest working is a critical requirement of pyjamas-desktop
[what's the point of having python bindings that are identical and a peer with
the javascript ones if AJAX is bloody well missing???! :) ]

2) removal of LANGUAGE_GOBJECT was requested several months ago because it
introduced features which are present in the de-facto Javascript standard (i.e.
anyone coming from javascript would not be in for some unpleasant surprises)
and it was stated that these features are not present in the W3C standard. 
after some extensive research, it was demonstrated that this wasn't quite true:
the W3C standard makes specific mention that certain browser engines _do_
support the features.  in fact, the research showed that by not having these
features (i.e. by conforming strictly to the W3C standards), webkit would in
fact be the _only_ major web engine that would not be on a par with its peers! 
even MSHTML has better support, because thanks to DCOM which has LP_VARIANT
(which can take int, string, or in fact anything) and thus, unlike any of the
other DOM implementations, the MS implementation of the DOM functions can
support _both_ the W3C standard _and_ the de-facto javascript-led standard.

regarding 2), i have put considerable thought to the matter and have some
insights to share.  from the perspective of the objective-c bindiings, strict
W3C DOM standards compliance may make perfect sense.  objective-c is a
_compiler_.  the auto-generated webkit objective-c header files are utilised at
_compile_ time by the compiler to perform type-checking that can result in
developers catching errors immediately.  and, in objective-c, developers can
take advantage of c++ classes that will be compiled, again at _compile_ time,
into type-converters that will take strings as input, and convert to integers,
and much much more.

however - the glib/gobject bindings will - and are - be utilised by INTERPRETED
languages.  there is a WHOPPING great world of difference.  there are two such
(auto-generated) language bindings already (vala and python), and there will be
more.

vala - https://bugs.webkit.org/attachment.cgi?id=27558

python - http://code.google.com/p/pywebkitgtk/issues/detail?id=13

in the python case, the (currently sole and exclusive) project which is using
pywebkitgtk with the DOM bindings is pyjamas - a python-to-javascript compiler.


in other words, the only test case - the only really big significant (free
software) test platform for the webkit glib bindings has a javascript-only
cousin.

that means that any applications written for pyjamas-desktop (which uses either
pywebkitgtk or XULrunner python-xpcom) can also run as javascript, in all major
web browsers.

_that_ means that application developers may be developing exclusively in
javascript, using the pyjamas python-to-javascript compiler.  then, they
encounter a requirement to have the application run as a stand-alone desktop
app.  then they download pywebkitgtk....

... and they get a nasty big shock because the bloody underlying API is subtly
different.  without LANGUAGE_GOBJECT, all toString() functions would be
missing; there would be no way to get the range of selected text out of input
nodes; embed nodes would suddenly lose their width and height settings;
XMLHttpRequest would be completely broken, and a few other nasty surprises.

not one of these things is acceptable.	the workarounds aren't particularly
nice, either, and - again, the workarounds would be _great_ if these were
COMPILED languages, with virtual base class function pointers etc. - but
they're not: they're INTERPRETED languages, just like javascript.

which reminds me of the other reason why many of the JS-isms should be enabled
(such as getBoxObjectFor).  again: in COMPILED languages, which are damn fast,
calling functions like getBoxObjectFor via two or three levels of indirection
makes absolutely no sense: just grab the attributes (width, height, top, left)
individually and directly and write your own version of getBoxObjectFor which
will, thanks to being a compiled language, be far far quicker.

NOT so, in interpreted languages such as python.  why?	well, have you ever
looked at python's Objects/abstractobject.c source code?  it makes for
interesting reading.  and that's where all object access starts out.  every
single add, multiply, etc. goes through potential coercion checking.  a single
optimisation is made to check whether the two types are "int", and this is the
_only_ case which is made faster: everything else goes through the "approx one
hundred lines of c-code" route.  just to do an add, or a multiply.

so the very reasons for which the javascript-isms were created are just as
equally valid for other dynamic languages as they are for javascript.

overall then, for many many reasons, there is an overall compelling case to be
made for sticking to the de-facto javascript standards over the W3C standards,
for the glib/gobject bindings, and as equally a compelling case to be made for
sticking to the W3C standards for the objective-C bindings.

the two should not be confused, and developers using interpreted languages
should not be put to incredible inconvenience (as well as the developers of the
intermediate bindings) just for the sake of it.

l.