[Webkit-unassigned] [Bug 27435] adding XMLHttpRequest send idl language gobject

[bugzilla-daemon at webkit.org]

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





--- Comment #28 from Mark Rowe (bdash) <mrowe at apple.com>  2009-08-03 10:07:05 PDT ---
(In reply to comment #26)
> (In reply to comment #25)
> > (In reply to comment #24)
> > >  honestly, there _really_ haven't been that many.
> > > 
> > >  there has in fact only been one: initKeyboardEvent.   that's literally the
> > > only one, so far.
> > 
> > XMLHttpRequest::send.
> 
> 
> #if (defined(LANGUAGE_GOBJECT) && LANGUAGE_GOBJECT)
>         void send(in DOMString data)
>             raises(DOMException);
> #else
>         [Custom] void send(in Document data)
>             raises(DOMException);
> #endif
> 
> 
> that's not altering the number of arguments; neither is it altering the
> "defaults".

It's a function that is overloaded.  It has three variants, all mentioned in
the specification for XMLHttpRequest.  One takes no arguments.  A second takes
a string.  A third takes a document.

You've outlined that you ran in to problems exposing the variant that takes a
Document and so opted not to do it.  That's fine.  What I'm looking for is an
outline of the general approach to how overloaded methods will be dealt with in
the bindings.  When we decide to expose send(Document) six months from now, how
will we do so in such a way that it doesn't conflict with send() and
send(DOMString)?

It's worth noting that send isn't the only method on XMLHttpRequest that this
applies to.  open is similarly overloaded:

  void open(in DOMString method, in DOMString url);
  void open(in DOMString method, in DOMString url, in boolean async);
  void open(in DOMString method, in DOMString url, in boolean async, in
DOMString user);
  void open(in DOMString method, in DOMString url, in boolean async, in
DOMString user, in DOMString password);

A similar approach would appear to be necessary here to prevent users from
being required to provide all of the available arguments.

Given that DOM bindings are typically exposed as API, these are the sorts of
issues that we need to be clear on from the start to avoid introducing
confusion and API compatibility issues down the track.

> additionally, it can be seen that the function is mutually exclusive to its
> Document counterpart.

It's not clear what you mean by this.

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