[whatwg] executeSql API is synchronous

[Aaron Boodman]

On Sep 25, 2007 11:08 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> I agree that the actual I/O to the database should be done up front.
> However, it should be possible to make the conversion from SQLite's
> native data types to JavaScript datatypes lazy (such type conversion
> can have nontrivial cost, especially in bulk). To do that and get
> Array-like behavior, you need either a custom Array subclass, or a
> class that doesn't inherit the Array implementation but does have the
> Array prototype in its prototype chain. But the current spec rules
> this out by requiring the result to be a "native Array". Furthermore,
> being a "native Array" requires support for mutation, which again
> makes custom strategies involving lazy type conversion more challenging.
>
> I would propose requiring that the row list object must have number-
> named properties for the contents, a read-only length property, and
> all Array prototype functions that do not modify the array somewhere
> in its prototype chain (this would include filter, forEach, map, but
> not sort or pop). I am not even sure the last part is necessary,
> because using Array.forEach is not *that* much more convenient than a
> for loop and is likely to be less efficient in many JS
> implementations. But if we want Array operations to be available, I'd
> suggest doing it in a way that does not constrain implementations to
> use a native Array.

Ah, that makes sense. A special purpose class for the rows property is
fine with me. I don't feel that strongly about forEach and friends.

- a