Re: [UndoManager] Re-introduce DOMTransaction interface?

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.

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

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

~TJ

Received on Monday, 9 July 2012 16:53:45 UTC