- From: Aaron Boodman <aa@google.com>
- Date: Tue, 25 Sep 2007 11:32:03 -0700
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
Received on Tuesday, 25 September 2007 11:32:03 UTC