Bug 27433 – enable toString function under gobject bindings

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit Misc.

[Luke Kenneth Casson Leighton]

this is part of the #16401 series of patches, split under an
agreement suggested by david.

code converted from javascript to python, to run under pyjamas-desktop via pywebkitgtk, expects to have toString, and breaks badly on finding that it doesn't exist.  this patch adds it in, for several reasons, which have been discussed in depth.  the discussion is still ongoing, and has been awaiting responses for nearly eight months.  twelve separate requests for answers have gone ignored.

opening this up as a separate dedicated bug request will keep the discussion to the subject at hand.

[Luke Kenneth Casson Leighton]

Created attachment 33062 [details]
adds toString to gobject bindings

there are a ton of good technical reasons why these should be added.  discussion of those technical reasons is welcomed.

[Mark Rowe (bdash)]

Comment on attachment 33062 [details]
adds toString to gobject bindings

As outlined before, toString is a JavaScript-specific method.

[Luke Kenneth Casson Leighton]

the research material is shown here:

https://bugs.webkit.org/show_bug.cgi?id=16401#c121

through to:


https://bugs.webkit.org/show_bug.cgi?id=16401#c124

[Luke Kenneth Casson Leighton]

Created attachment 33067 [details]
adds toString to gobject bindings

whoops, referenced wrong bug # in ChangeLog.

has the research material been reviewed?

i have not received a satisfactory review response indicating that the research material has been reviewed.

if a satisfactory answer is given, i will no longer request review of this patch.

if an unsatisfactory answer is given indicating that the research material has not been reviewed and has not been taken into consideration, the flag will go up each and every time is it removed, without fail.

[Luke Kenneth Casson Leighton]

(In reply to comment #2)
> (From update of attachment 33062 [details])
> As outlined before, toString is a JavaScript-specific method.
 
 that is irrelevant. read the research material.

[Mark Rowe (bdash)]

Comment on attachment 33067 [details]
adds toString to gobject bindings

Marking as r- for reasons previously noted.

[Luke Kenneth Casson Leighton]

Comment on attachment 33067 [details]
adds toString to gobject bindings

come on, mark - the burden on developers to "recreate" toString is immense.  every language-bindings developer will have to create a secondary wrapper, doing something like this:

def toString(element):
    if ENGINE.type != "webkit":
        return element.toString()

    # ok, xulrunner and MSHTML have toString,
    # but webkit's team are being a pain, forcing
    # us to work out what the element type is
    # and... never mind, let's just get on with it

    # first determine what type of element this is
    if hasattr(element, "nodetype"):
       # ok it's likely to be an HTML element.
       # now we work out if it's a comment
       # etc. etc.
       if element.nodetype == 1:
           # ok, it's an HTML element.
           nodename = element.nodename
           return "<%s>" % nodename +
                  element.innerHTML +
                  "</%s>" % nodename

    # ok, it wasn't an HTML element - is
    # it an exception?  let's guess...
    
    if hasattr(element, "message") and
       hasattr(element, "name"):

        # ok - exceptions have name and
        # message.

        return element.name + element.message

    # ok, what about DOMSelection?

    # etc.

    # etc.



so you can see that to burden even _one_ dynamic
language with this kind of stuff is just absolutely
ridiculous - and that's just one application.

all applications will need to apply this same
awful trick - i don't dare to think what a mess
of spaghetti code there would be if someone
wanted to do this in native c!

all that spaghetti goes away if there are toString
functions which can be assumed to be in each of
the objects.  in the case of the pyjamas API
which uses pywebkitgtk, python takes care of
the mapping, and it's a 2-line function:

def toString(element):
    return element.toString()


if these functions weren't available to all language bindings in XULrunner, KHTML and MSHTML, i wouldn't be pushing this issue - yes, i'd simply not bother and would even consider removing toString from the pyjamas API, and let users get on with it.

but - it's there, and it's in the GWT API so we have to conform with it.

so, very sorry, but i'm re-raising the review flag until this is properly looked at.

an answer "yes we have looked at the research material which shows yes that the all of the current web browser competitor technology to webkit can clearly seen to support the fact that toString is part of de-facto standards... <complete sentence>" is what i expect.

if there is anything which does not mention "the research material has been examined" i will instantly re-submit the patch for review.

sorry.

[Sam Weinig]

Comment on attachment 33067 [details]
adds toString to gobject bindings

Please do not continue to remark for review patches that have been r-'ed already.  Continuing to do so will have your account suspended.  As Mark noted, toString() is a JS concept that does not map to other languages and is therefore not suited for the C GObject bindings.

[Luke Kenneth Casson Leighton]

sorry, sam, you appear not to have read the research material which shows that toString is supported by c++, python, COM and other language bindings by XULRunner, MSHTML and KHTML (even if it's called toHTML not toString in KHTML).

when is the research material going to be reviewed?

for your convenience, i'm copying the relevent sections from #16401 which show that toString is supported by webkit's peers.

when you have reviewed this material, and have answered, "yes we have read this material, and have taken it into consideration in making a decision, and our decision is: xyz because of abc" then i will stop.

and i absolutely will not stop and i will fight every single corner that there is on these DOM bindings without fail and without mercy and without letting you give one single inch without giving a full and thorough explanation of every single decision that you make so that future people looking at this can get a full and accurate and _transparent_ picture of everything that goes on.

so - get used to this.

provide a full, complete explanation and justification for review decisions.

in this case, starting with, "why is toString a JS-ism for webkit and webkit alone?"

or, provide me with evidence that toString is a JS-ism for other browser engines.

_that_ i will happily accept (because it will bugger up pyjamas-desktop from _two_ browser engines, rather than just one, and i will _have_ to make an exception).


 ------  Comment #121 From  Luke Kenneth Casson Leighton   2009-01-01 06:38:13 PDT   (-) [reply] -------

IHTMLStyle.toString:
http://msdn.microsoft.com/en-us/library/aa768820(VS.85).aspx

IDOMTextNode.toString:
http://msdn.microsoft.com/en-us/library/aa704073(VS.85).aspx

IHTMLElement.toString:
http://msdn.microsoft.com/en-us/library/aa752332(VS.85).aspx

IHTMLElementCollection.toString:
http://msdn.microsoft.com/en-us/library/aa703933(VS.85).aspx

IHTMLSelectElement.toString:
listed in wine-dev's mshtml.idl file - so we know it exists - but it's not
actually listed in the msdn online documentation.  IHTMLSelectElement has
_five_ extensions (1-5 _and_ an Ex!) so it doesn't surprise me that the docs
are out-of-date.

IOmNavigatorElement.toString:
http://msdn.microsoft.com/en-us/library/aa703735(VS.85).aspx

IHTMLLocation.toString:
http://msdn.microsoft.com/en-us/library/aa703648(VS.85).aspx

IHTMLWindow2.toString:
http://msdn.microsoft.com/en-us/library/aa741504(VS.85).aspx

IHTMLDocument2.toString:
http://msdn.microsoft.com/en-us/library/aa752636(VS.85).aspx

IHTMLCommentElement.toString:
exists in wine-dev mshtml.idl so we know it exists but it is not listed in the
msdn documentation.

------- Comment #122 From Luke Kenneth Casson Leighton 2009-01-01 06:49:53 PDT (-) [reply] -------

relevant sections for XUL / Gecko.  note the warnings at the top of each and
every one of these pages: the 1.9 documentation _is_ relevant (as they define
the interfaces)

http://www.xulplanet.com/references/xpcomref/ifaces/nsIScriptError.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsIMsgIdentity.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsIException.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsIMsgAccount.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsIDOMRange.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsISupportsPRUint32.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsIMsgIncomingServer.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsISupportsString.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsIDOMToString.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsIJSID.html#method_toString
http://www.xulplanet.com/references/objref/Location.html#method_toString
http://www.xulplanet.com/references/objref/Selection.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsIAtom.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsISelection.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsIPrefLocalizedString.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsIStackFrame.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsIDOMLocation.html#method_toString
http://www.xulplanet.com/references/xpcomref/ifaces/nsIDOMDOMConstructor.html#method_toString

------- Comment #123 From Luke Kenneth Casson Leighton 2009-01-01 07:12:41 PDT (-) [reply] -------

example useage of PyKDE's KHTMLPart document.toString() function:

http://www.mail-archive.com/[e-mail]/msg09577.html

unfortunately, the discussion centres around how the function causes a
segfault!

but the documentation on Document.toString's existence, in the KDE HTML DOM
model bindings, is here:
http://developer.kde.org/documentation/library/3.3-api/khtml/html/classDOM_1_1Document.html

hmmm.. that seems a bit out-of-date, here's a more up-to-date one:
http://api.kde.org/3.5-api/kdelibs-apidocs/khtml/html/classDOM_1_1Document.html#fa3edf3819e0dc6ccf120e5e5d462ccf

there's also a kde 4.x and a kde 4.1 version.

there is however also a toHTML() function in DOMNode, which is listed as
"deprecated" - presumably someone decided that calling toString "toHTML" was a
bad idea.

ah!  finally!  i found a by-function-name reference:
http://api.kde.org/4.0-api/kdelibs-apidocs/khtml/html/functions_0x74.html

which shows that the two occurrences of toString() are in DOM::Document
and DOM::Range:

http://api.kde.org/4.0-api/kdelibs-apidocs/khtml/html/classDOM_1_1Range.html#2358111339856f9a61bf0456d03daf3a

also, it looks like DOM::Node.toHTML _didn't_ get deprecated, after all,
and is still there:
http://api.kde.org/4.x-api/kdelibs-apidocs/khtml/html/classDOM_1_1Node.html#249840ef6631b425d7ced51397545b32


so, overall, KDE's KHTMLPart interface has a limited supply of "toString"
functions [which make it a far-from-ideal candidate as a target for
pyjd but that's another story] but it _does_ actually _have_ the most
important toString functions - the ones for DOM::Document and DOM::Range.

------- Comment #124 From Luke Kenneth Casson Leighton 2009-01-01 07:19:56 PDT (-) [reply] -------

from the quoted references to "toString" which can clearly be shown
to exist in all the major browser engines - not specifically limited
to "javascript" but to all the major browser engines' generic language
bindings - it can be concluded that leaving out "toString" because it
"isn't in the W3C specification" would be a serious mistake.

that, given the prevalent support for "toString" in all other
competitor products to webkit, users of webkit DOM bindings
_would_ find it irritatingly odd that "toString" is missing.

i have to be honest with you, i was a bit surprised to find that
IE's MSHTML.idl definition file supports it! :)

wine's reverse-engineered version of mshtml.idl is here:
    http://source.winehq.org/source/include/mshtml.idl

this illustrates why i have been advocating that javascript's
bindings should be the guiding light.

i trust that i no longer have to go through such extreme lengths
to demonstrate the case for javascript's de-facto standard being
authoritative over the W3C "non-real-world" standard.  there are
over 300 objects, 1500 functions and tens of thousands of
properties, and that's _without_ the SVG canvas bindings and
without having enabled HTML5 video support (which i haven't
tried yet).

to have to go through "justifying" every single difference would
be tedious in the extreme.

[Luke Kenneth Casson Leighton]

Created attachment 33380 [details]
for convenience of the reviewers, this patch includes the research material which is not being read and answered as part of the prior review comments, which has been requested seventeen times so far

for your convenience, i'm including the research material in the ChangeLog, showing evidence of the existence and support of toString in all competitor browser engines, in their language bindings.  MSHTML's DCOM interface.  XULrunner's native c++ and XPCOM bindings.  KHTML with its toHTML (because QObject already has a function called toString, with which the name toHTML obviously clashes).

perhaps you could see your way to reviewing the attached patch, along with the supporting evidence, which is different from the one previously submitted.

[Luke Kenneth Casson Leighton]

(In reply to comment #8)
> (From update of attachment 33067 [details])
> Please do not continue to remark for review patches that have been r-'ed
> already. 

 with respect: please answer the question raised by the research material.
 wodging the issue and making threats does not answer the question [and
 won't work].

[Luke Kenneth Casson Leighton]

(In reply to comment #11)
> (In reply to comment #8)
> > (From update of attachment 33067 [details] [details])
> > Please do not continue to remark for review patches that have been r-'ed
> > already. 
> 
>  with respect: please answer the question raised by the research material.
>  wodging the issue and making threats does not answer the question [and
>  won't work].

 that was request numbered eighteen, that your review answer take into
 consideration the research material.

[Mark Rowe (bdash)]

Comment on attachment 33380 [details]
for convenience of the reviewers, this patch includes the research material which is not being read and answered as part of the prior review comments, which has been requested seventeen times so far

As we've mentioned repeatedly: we do not feel that it is appropriate to expose toString methods outside of JavaScript.  The toString function is a JavaScript concept that does not map directly to other languages.  They are not part of the DOM itself.  The information they expose is available via existing means.

[Luke Kenneth Casson Leighton]

(In reply to comment #13)
> (From update of attachment 33380 [details])
> As we've mentioned repeatedly: we do not feel that it is appropriate to expose
> toString methods outside of JavaScript.  The toString function is a JavaScript
> concept that does not map directly to other languages.  They are not part of
> the DOM itself.  The information they expose is available via existing means.

 yet the burden of _getting_ that information is so onerous that all other competitor products to webkit have just gone "fine - let's just make it available".

 do you accept this?

 or do you consider it reasonable to impose a massive development burden onto webkit developers, when it would be so incredibly easy to make their lives much much easier?

 do you accept this?

 for the record - for archival purposes and so that people can see in the future why it was not added, and to whom they need to address their concerns - please state yes or no to each of the two questions, above.

l.

[Mark Rowe (bdash)]

(In reply to comment #14)
> (In reply to comment #13)
> > (From update of attachment 33380 [details] [details])
> > As we've mentioned repeatedly: we do not feel that it is appropriate to expose
> > toString methods outside of JavaScript.  The toString function is a JavaScript
> > concept that does not map directly to other languages.  They are not part of
> > the DOM itself.  The information they expose is available via existing means.
> 
>  yet the burden of _getting_ that information is so onerous that all other
> competitor products to webkit have just gone "fine - let's just make it
> available".
> 
>  do you accept this?

No.

1) You're assigning a reason for why other libraries include this with no basis for doing so.
2) In almost all cases it is trivially available as a property of the object in question.  I say "almost all" only because I've not memorized the entire DOM, not because I'm aware of any objects for which this is not the case.

>  or do you consider it reasonable to impose a massive development burden onto
> webkit developers, when it would be so incredibly easy to make their lives much
> much easier?
> 
>  do you accept this?

Given that no massive burden is being imposed there isn't anything here for me to agree with.

>  for the record - for archival purposes and so that people can see in the
> future why it was not added, and to whom they need to address their concerns -
> please state yes or no to each of the two questions, above.

Luke, my dear man, I do think you should consider checking your ego at the door in the future.

[Luke Kenneth Casson Leighton]

> > > toString methods outside of JavaScript.  The toString function is a JavaScript
> > > concept that does not map directly to other languages.

 this statement indicates that you do not understand.

 so - next set of questions.

 the toString function has, behind it, a lot of thought (by its original creators) and in each object which supports it, there is a heck of a lot of work.

 am i right in thinking that it would be perfectly possible to implement toString, for each object, _in_ javascript itself?  (HTMLElement.toString could be implemented in terms of <nodename>{innerHTML}</nodename>; Exceptions in terms of name + message etc.)

 i believe that i am [but welcome corrections].

 given that this is the case, why do you think that the original creators went to the trouble of adding "toString" to each of the objects, when that burden of effort could just equally be done by the _users_?

 
 do you appreciate that it is somewhat ridiculous to burden developers with the effort spent in implementing these functions, given that:

 a) it's already been done [in webkit, xulrunner _and_ MSHTML] for javascript?

 b) the implementers of this extra burden of work might get it _wrong_ - non-de-facto-standards-compliant wrong?


 do you accept that there is a real-world use-case for making toString available, so that it is possible to do unit-tests on libraries and APIs?

 for example, in the web browser version of pyjamas, toString is available.  it's therefore possible to write some DOM-manipulation code unit tests, call the toString function on the resultant DOM object and compare it against the expected results.

 then, in the XULrunner version, the same code (no longer compiled to javascript but executed directly as python, using python-xpcom bindings) can be run, and the same unit tests carried out, thus validating both the unit tests _and_ the XULrunner API itself, against the five different browser implementations (IE, opera, safari, mozilla and netscape).

 likewise in the MSHTML version (currently under development).

 and... for the webkit version?  *poof*.  not possible.  why?  because the toString functions aren't going to be made available.

 so - do you accept that there is a real-world benefit to providing toString?

[Mark Rowe (bdash)]

(In reply to comment #16)
> > > > toString methods outside of JavaScript.  The toString function is a JavaScript
> > > > concept that does not map directly to other languages.
> 
>  this statement indicates that you do not understand.

I understand.  I just happen to disagree.

>  am i right in thinking that it would be perfectly possible to implement
> toString, for each object, _in_ javascript itself?  (HTMLElement.toString could
> be implemented in terms of <nodename>{innerHTML}</nodename>; Exceptions in
> terms of name + message etc.)

HTMLElement.toString is the default version defined by the JavaScript language in that it returns "[object HTMLElementConstructor]".  Not all that useful.

>  for example, in the web browser version of pyjamas, toString is available. 
> it's therefore possible to write some DOM-manipulation code unit tests, call
> the toString function on the resultant DOM object and compare it against the
> expected results.

Given that most of the toString methods in JavaScript return "[object TypeName]" as outlined above, this wouldn't be a particularly useful thing to do in the general case.  In order to use of toString in a useful manner, you have to be aware of the type that you're working with.  Since you're required to be aware of the type, you can easily make the more explicit, type-specific call to retrieve the information you're after.

>  so - do you accept that there is a real-world benefit to providing toString?

No.

[Mark Rowe (bdash)]

And Luke, reopening bugs repeatedly is a lot like flagging the same patch for review repeatedly.  Please don't.

[Luke Kenneth Casson Leighton]

(In reply to comment #18)
> And Luke, reopening bugs repeatedly is a lot like flagging the same patch for
> review repeatedly.  Please don't.

 and so is - was - not responding to comments.  now that you've kindly done so, providing detailed responses, i can now raise the matter with the HTML5 spec group.