On Fri, Jul 6, 2012 at 1:46 AM, James Graham <jgra...@opera.com> wrote:
> On 07/06/2012 02:01 AM, Ryosuke Niwa wrote: > >> On Thu, Jul 5, 2012 at 4:27 PM, Ojan Vafai <o...@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