[Webkit-unassigned] [Bug 27433] enable toString function under gobject bindings

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jul 23 14:50:33 PDT 2009


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


Luke Kenneth Casson Leighton <lkcl at lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WONTFIX                     |




--- Comment #9 from Luke Kenneth Casson Leighton <lkcl at lkcl.net>  2009-07-23 14:50:32 PDT ---
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.

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



More information about the webkit-unassigned mailing list