W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [UndoManager] Re-introduce DOMTransaction interface?

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Fri, 6 Jul 2012 12:09:20 -0700
Message-ID: <CABNRm614=ZMOTi6PL7ur=uC2qkFRoGW9BUkExhguHvb6QZE38w@mail.gmail.com>
To: James Graham <jgraham@opera.com>
Cc: public-webapps@w3.org
On Fri, Jul 6, 2012 at 1:46 AM, James Graham <jgraham@opera.com> wrote:

> On 07/06/2012 02:01 AM, Ryosuke Niwa wrote:
>
>> On Thu, Jul 5, 2012 at 4:27 PM, Ojan Vafai <ojan@chromium.org> wrote:
>>
>
>  In your version, you need to remember the order of the arguments, which
>>> requires you looking it up each time. If we do decide to add the
>>> DOMTransaction constructor back, we should keep passing it a dictionary
>>> as
>>> it's argument. Or maybe take the label and a dictionary as arguments.
>>>
>>>
>> That's true of almost all other Web APIs when used in ECMAScript 5. I'm
>> not
>> sympathetic to the argument that you have to remember orders in which
>> arguments appear because that's true of all functions in ES5, C++, and
>> various other programming languages.
>>
>
> That just isn't true. Many web APIs solve the lack of named arguments in
> javascript by accepting an object with arguments. For example both jQuery
> and prototype use this pattern in their XHR APIs. Insofar as it doesn't
> follow this pattern, DOM is very much the odd one out.


Okay, it appears to be a miscommunication of terminology here. What I meant
is DOM APIs in your definition. As Adam said, API fashions come and go. We
should be making new DOM APIs consistent with existing DOM APIs.

I personally find "named arguments" in various library functions annoying
especially when there are only few arguments. e.g.
parent.appendChild({child: node}); would be silly.

 - Ryosuke
Received on Friday, 6 July 2012 19:10:08 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:53 GMT