On Thu, 5 Jul 2012, Ryosuke Niwa wrote:
On Thu, Jul 5, 2012 at 8:08 AM, James Graham <jgra...@opera.com> wrote:
On 07/05/2012 12:38 AM, Ryosuke Niwa wrote:
After this change, authors can write:
scope.undoManager.transact(new AutomaticDOMTransaction{function () {
scope.appendChild("foo");
}, 'append "foo"'));
[...]
document.undoManager.transact(new DOMTransaction({function () {
// Draw a line on canvas
}, function () {
// Undraw a line
}, function () { this.execute(); },
'Draw a line'
}));
I think this proposed API looks particularly verbose and ugly. I thought we
wanted to make new APIs more author
friendly and less like refugees from Java-land.
What makes you say so? If anything, you don't have to have labels like execute,
undo, and redo. So it's less verbose. If you
don't like the long name like AutomaticDOMTransaction, we can come up with a
shorter name.
I think having to call a particular constructor for an object that is just
passed straight into a DOM function is verbose, and difficult to
internalise (because you have to remember the constructor name and case
and so on). I think the design with three positional arguments is much
harder to read than the design with three explicitly "named arguments"
implemented as object properties.
Also, I think consistency matters a lot here. I'm not aware of any other
Web-facing API that takes a pure object with
callback functions.
I think Olli mentioned some already, but the obvious example is event
handlers which take a pure function or an object with a handleEvent
property.
Passing in objects containing one or more non-callback properties is also
an increaingly common pattern, and we are trying to replace legacy APIs
that took lots of positional arguments with options-object based
replacements (e.g. init*Event). From the point of view of a javascript
author there is no difference between something like {foo:true} and
{foo:function(){}}. Insisting that there should be a difference in DOM
APIs because of low-level implementation concerns is doing a disservice to
web authors by increasing the impedence mismatch between the DOM and
javascript.
On Thu, Jul 5, 2012 at 11:07 AM, Olli Pettay <olli.pet...@helsinki.fi> wrote:
We shouldn't change the UndoManager API because of implementation issues,
but if event based API ends up being
better.
I don't think it's reasonable to agree on an unimplementable design. In theory,
mutation events can be implemented correctly
but we couldn't, so we're moving on and getting rid of it.
That's true, but based on the content of this thread, not relevant to the
issue at hand.
The current deisgn is not "unimplementable", it's just slightly more work
in WebKit than you would like. I don't think it's reasonable to reject
good designs in favour of worse designs simply because the better design
isn't a perfect fit for a single implementation; from time to time we all
have to make larger changes to accomodate use cases that weren't
considered when architecting our code (beforeunload in Opera is a case in
point).
