[Webkit-unassigned] [Bug 16401] [GTK] GObject/C DOM binding

Wed Dec 31 07:52:27 PST 2008

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

------- Comment #117 from lkcl at lkcl.net  2008-12-31 07:52 PDT -------
(In reply to comment #91)
> (In reply to comment #88)
> > (In reply to comment #87)
> > >  #if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT)
> > >         [DontEnum] DOMString toString();
> > >  #endif
> > > 
> > > toString() is also a JavaScript language concept that other bindings need to
> > > worry about.
> > 
> >  i do keep explaining - but it's been a while so i will explain it again:
> > javascript is the language that i am targetting as providing _direct_
> > one-for-one, concept-for-concept, function-for-function, class-for-class,
> > attribute-for-attribute equivalence (as closely as possible).
> 
> In that case, your objective is not the same as the objectives of the DOM
> bindings in WebKit.  As I have stated, they are designed to wrap the standard
> WebKit DOM, and only to expose quirks to JavaScript where they are required for
> compatibility with other browsers.

 and, logically by extension, webkit being a browser engine, all applications
 _based_ on webkit thus being browsers, "quirks to Javascript" must be
"exposed"
 without fail and without exception on _all_ bindings, such that all
 applications work from the same "standard".

 even if it's a damn stupid one that's dictated by real-world stupidity
 rather than a clean design from W3C.

> The DOM is not JavaScript. 

 i'm fully aware of that.  however, that has nothing to do with the
 DOM _standard_ being over-ridden by IE5, IE6, IE7, IE8, Firefox, Mozilla
 all getting that DOM standard completely wrong, thus forcing the
 DOM standard - as viewed through the eyes of Javascript Bindings - to
 be subtly different.

> I don't think the argument that a developer expects
> to see JavaScript semantics from a non-JavaScript DOM binding holds much
> weight. 

 well the fact that you don't see that means that the pyjamas-desktop project
 must be terminated, as there is absolutely zero point in proceeding to use
 webkit (the best and currently only reasonable and viable option to providing
 python bindings to a fully-functioning DOM model).

 so - thank you: the fact that you are unable to see that means that apple
 is responsible for destroying the progress of free software development.

> We've had no complaints of this nature, about the Objective-C DOM
> bindings in the many years that they have been part of the project. 

 i would consider that to be an indication that no serious objective-c
 DOM project has ever been developed - certainly not one that covers
 almost 100% of the functionality of the DOM model.

 the pyjamas-desktop project covers quite literally absolutely every
 corner of the DOM model: when porting pyjamas to pyqt4, that failed
 because of limitations in pyqt4.  when porting it to pygtk2, that failed
 even quicker, due to more significant limitations.  when porting it to
 python-pykde, _that_ turned out to have really subtle limitations
 (c++ RTTI has been disabled, and the equivalent of the HashMap in
 JSBindings.cpp and GDOMBindings.cpp utterly relies on RTT) and so _that_
 port failed as well.

 due to the nature of what pyjamas-desktop is, it squeezes every corner of
 its underlying technology until the pips squeak.

> > the same thing goes for the "constructors" (if i can get my head round why
> > they're used).
> 
> Are you seriously arguing that you must have something that you don't
> understand?  The JavaScript constructors are used only for gaining access to
> the prototype object, a JavaScript concept, which simply does not make sense
> for other DOM bindings.
> 
> > the same thing also goes for the suggestion that you made that i should
> > provide only "integer" input to setWidth() and other functions, because that's
> > what ObjC does.
> > 
> >  the answer's "no - absolutely not".  people who expect to pass in "3em",
> > "10px", "50%" will get a nasty shock.
> 
> As I have already stated, people that try and set .width or .height "3em" will
> already get a nasty shock, even from JavaScript.  It does not do what you think
> that it does.

 i don't care!  if they get a nasty shock from javascript, and they then get
the _same_ nasty shock from the gobject bindings _great_.

 bug-for-bug.  feature-for-feature.  nasty-shock-for-nasty-shock.
 as the guardians of webkit, it's not our job to "care" what happens.

> >  and yes, i really really _do_ need toString() because it's actually _used_ in
> > the pyjamas-desktop DOM.py module.
> 
> This argument doesn't carry much weight, as it could be used to get *any*
> change in to WebKit. 

 i don't know how to respond to this.

 you seem unable to accept reasonable real-world usage as justification
 for providing specific functionality, without which the project i'm working
 on - the only example and _the_ leading free software example - is dead.

 gecko's language bindings provide toString.

 python-pykde, KHTMLPart's language bindings provide toString.

 webkit's javascript language bindings provide toString.

 why are you "dictating" that the webkit gobject bindings should _not_ have
toString, when you are being _specifically_ told that a project _needs_ that
functionality?

> It can be generalised to: "I've written some code in
> another project that depends on my work-in-progress patch, therefore you have
> to accept this change in to WebKit in order to not break that code."

 it's not about "breaking" that code - that "code" is DEAD without it.

> All of the objects that provide a .toString() function to JavaScript there are
> native DOM methods to return the same data.

 so what?

>  Applications using the native DOM
> bindings can simply use the appropriate methods to retrieve this information.

 so, i must write some code, "if in pyjamas-desktop, the library being used
equals webkit, and the object does not have a toString function, then detect
what type it is and then from there work out the quotes appropriate method
quotes' else if the library being used is python-gecko, call the toString
function, else if the library is python-pykde, call the toString function".

 not going to happen.

 please ask the gecko developers to remove toString from their language
 bindings, and see how far you get.

 please also ask the KDE KHTML developers to remove toString from their
 language bindings, and see how far you get.

> >  remember, i'm translating the javascript (by hand, unfortunately) in pyjamas
> > into DIRECT and IDENTICAL function calls (in python) that end up calling the
> > webkit-glib bindings.
> > 
> >  if i get *any* discrepancies (such as not having toString), then all of a
> > sudden i'm screwed, because there's a difference between the pyjamas code
> > (javascript compiler) and the pyjamas-desktop code (webkit-based).
> 
> I think you need to keep in mind that DOM bindings in WebKit do not exist
> solely for the benefit of your project.

 i'm well aware of that.

>  Your project, as the first user of the
> DOM bindings, certainly influences what the initial cut will support, but it in
> no way defines what they *must* support.

 mark.

 you are being dictatorial, unreasonable, and deliberately obstructive.

 why do you _care_ whether there is a toString function that some NONEXISTENT
 projects may or may not use, ESPECIALLY when the ONLY project - that obviously
happens to be the first - is TELLING you it needs that function, and is TELLING
you that all OTHER language bindings provide that function?

 why do you _care_ about _deliberately_ sticking to the W3C DOM standards, when
you're being told that to do so will result in failure of a project?

 is there something that you're not telling us?  are you being _paid_ or being
instructed by your employer to be deliberately obstructive, and to delay or
otherwise scupper the usefulness of the gobject DOM bindings?  because that's
the only possible explanation that i can think of that makes any sense.

 the other possibility is that you're being obstructive just for the sake of
it,  to gain some feeling of power or something.

 instead of dictating what should or should not be in the gobject bindings,
which you have _no_ experience of using and the use of which is _not_ in your
area of expertise, you should be encouraging this first project that uses them
to be successful, as the leader and pathfinder.

 i am perfectly happy to listen to your advise and to learn from your expertise
in the inner workings of webkit - your expertise and knowledge of the
ref-counting and other technical areas has been absolutely invaluable, and in
many other areas as well.

 however, for you to respond to reasonable justification for specific features
 with "that could be a justification to put _anything_ into webkit" is
 completely unprofessional.

 it's called "moving the goalposts", so that you "win".

 you want to "win" - and be a bully while you're at it.

 i'm sorry to have to be pointing these things out - i really wish i didn't
 have to be the one to draw these conclusions.  but anyone reviewing these
 records will be able to draw the same conclusions, and likewise wonder why
 you're being unreasonably obstructive.

 l.

-- 
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.