On 07/12/2012 12:07 PM, Yuval Sadan wrote:
I think we need to realize that a lot of the APIs that have been
designed in the past aren't terribly good APIs.
The IndexedDB API is rather new, and the manner in which it consistently uses
event handlers on returned objects is rather innovative. The
DOMTransaction object is more similar to that.
In other words, I think it's more important to focus on what makes a
good API, than what is consistent with other DOM APIs.
Consistency has its value. Even if some is lacking, fixing it in some places
and not in others might cause a jumble. Which is my feeling actually
about the IndexedDB API. Adding more syntactical variations can lead to hectic
code.
However, I agree that it's not the primary concern.
Something that I really liked about the old API was the fact that
using it created very intuitive code. Basically you just write a class
the way you normally would write a class, and then pass in your
object:
x = {
someState: 0,
apply: function() { this.someState++; this.modifyDOM(); },
unapply: function() { this.subState--; this.modifyDOMOtherWay(); },
...
};
undoManager.transact(x);
You can even do things like
undoManager.transact(createParagraphTransaction(params));
How's that different from:
function createParagrahTransaction(params) {
x = new DOMTransaction("Create paragraph");
x.apply = function() { ... use params... };
x.onundo = function() { ... use params ... };
return x;
}
Also, in your example, I think that in the JS-object proposal you won't be able
to reference the original object's properties -- it will be lost, and
'this' is window.
'this' would be the object, not window when callback object is used.
The fact that we have to choose between creating APIs that feel like
"DOM APIs" or "JS APIs" I think is an indication that "DOM APIs" are
doing things wrong. There should be no difference between "DOM APIs"
and "JS APIs".
It is a problem. But WebIDL and JS aren't two of the same.
