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

[bugzilla-daemon at webkit.org]

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





------- Comment #91 from mrowe at apple.com  2008-10-17 16:55 PDT -------
(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.

>  this approach allows developers who are _expecting_ to see javascript,
> _understand_ javascript and program regularly in javascript to _not_ get any
> nasty surprises when they are presented with the glib bindings, and other
> language bindings to those.

The DOM is not JavaScript.  I don't think the argument that a developer expects
to see JavaScript semantics from a non-JavaScript DOM binding holds much
weight.  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. 

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

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

All of the objects that provide a .toString() function to JavaScript there are
native DOM methods to return the same data.  Applications using the native DOM
bindings can simply use the appropriate methods to retrieve this information.


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


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