Re: [UndoManager] Re-introduce DOMTransaction interface?

Another thing to consider if we add DOMTransaction back in is that you now
need to specifiy what happens in more cases, e.g.:
-call transact on the same DOMTransaction twice
-call transact on a DOMTransaction then modify undo/redo listeners

These are solvable problems, but are just more complicated than using a
dictionary. I really see no point in adding DOMTransaction back. If you
want, you could make transact just take the arguments you want
DOMTransaction to take. Then of course, you end up in the case of needing a
bunch of optional arguments due to automatic vs. manual transactions, which
leads us back to using a dictionary.

An alternative interface I'd be happy with would be transact(String label,
Dictionary optionalArguments) since label is always required.


On Mon, Jul 9, 2012 at 10:19 AM, Ryosuke Niwa <rniwa@webkit.org> wrote:

> On Mon, Jul 9, 2012 at 9:52 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:
>
>> On Mon, Jul 9, 2012 at 9:41 AM, Ryosuke Niwa <rniwa@webkit.org> wrote:
>> > 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:
>> >> > 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.
>>
>> Irrelevant to the discussion.  Nobody's suggesting to adopt other
>> Pythonisms.  I was just pointing to Python to support my assertion
>> that this is now a very popular pattern, not a transient fashion.
>>
>
> And I was saying that just because Python does it, it doesn't mean it's
> desirable nor does it support your assertion.
>
> > 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)
>>
>> Yes, and it would be wonderful if JS had similar support so that we
>> could easily accommodate both patterns.  It doesn't, and so we have to
>> choose one or the other.
>>
>
> Yes, but that should be addressed in TC39.
>
>  > On the other hand, other popular programming languages like Java and C++
>> > don't support named arguments.
>>
>> Of course.  They, like the DOM APIs, are old (hell, C++ is older than
>> you or me).  Evolution happens.
>>
>
> >>> 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.
>>
>> I don't get it.  That doesn't seem like a logical ordering to me.
>
>
> It is because that's the order in which these functions can be called. You
> can't call redo before calling undo, and you can't call undo before execute.
>
> By that I mean, there's no clear reason for me to assume, having not used
>> this API before, that they should appear in that order, nor is there
>> an existing well-established pattern across many other APIs that they
>> appear in that particular order.
>>
>
> Undo appearing before Redo is a very well established pattern:
> http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html
>
> https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUndoManager_Class/Reference/Reference.html
>
> Having execute is somewhat odd because there are no other frameworks in
> which such a function appears in an object that represents undo/redo.
> That's another reason I like Yuval's proposal over the current design.
>
> - Ryosuke
>
>