Re: [UndoManager] Re-introduce DOMTransaction interface?

On Fri, Jul 6, 2012 at 12:09 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
> 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.

While API fashions do change, this doesn't appear to be a fashion.  A
ton of popular libraries have been doing this for years, and it
doesn't seem to be flagging.  Language-supported variations of this
pattern exist in other popular languages as well, such as Python.

Ordered arguments are simply difficult to use, and people designing
things nowadays often choose to avoid them by using named arguments.

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

Come on, Ryosuke, don't strawman.  Obviously when there's only a
single argument, there's no concerns about remembering the order.  Two
args are often fine, but PHP shows us quite clearly that's it's easy
to screw that up and make it hard to remember (see the persistent
confusion in PHP search functions about whether the needle or haystack
comes first).  Three and up, you should definitely use named args
unless there's a strong logical order.  (For example, an API taking a
source and dest rectangle can reasonably support 8 ordered args,
because "x,y,w,h" and "source,dest" are strong logical orders.)

In this case, there is no logical ordering for the callbacks.  They
should be named args.

~TJ

Received on Monday, 9 July 2012 14:31:29 UTC