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.
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.
Comment on attachment 33062 [details] adds toString to gobject bindings As outlined before, toString is a JavaScript-specific method.
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
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.
(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.
Comment on attachment 33067 [details] adds toString to gobject bindings Marking as r- for reasons previously noted.
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.
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.
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/pyqt@riverbankcomputing.com/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.
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.
(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].
(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.
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.
(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.
(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.
> > > 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?
(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.
And Luke, reopening bugs repeatedly is a lot like flagging the same patch for review repeatedly. Please don't.
(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.