Re: [UndoManager] Re-introduce DOMTransaction interface?

On Mon, Jul 9, 2012 at 7:30 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

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

Yeah, and Python does all other things I don't like e.g. using indentation
instead of { } or begin/end. Also, we're not forced to use named arguments
in Python. If we have a function like:

def transact(execute, undo, redo):
    ~~

you can call it as either:
transact(execute=a, undo=b, redo=c)
or
transact(a, b, c)

On the other hand, other popular programming languages like Java and C++
don't support 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 our case, there's a clear logical ordering: execute, undo, redo.

In this case, there is no logical ordering for the callbacks.


But they do!

Anyway, all of this argument doesn't really matter because Yuval's current
proposal doesn't involve 2nd or 3rd arguments. It only has 2 arguments:
label and execute, and undo and redo are set forth by property assignments.

- Ryosuke