- From: Keean Schupke <keean@fry-it.com>
- Date: Tue, 3 May 2011 15:56:10 +0100
- To: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Pablo Castro <Pablo.Castro@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
- Message-ID: <BANLkTikHS5XNHpn7pEt+v9g4K8a86nv8sQ@mail.gmail.com>
Why does it need to be persisted? I would prefer the database to be stateless. Obviously all users of the database need to use the same function. I would recommend modular programming - create a .js script you can include in all pages that provides 'collated' versions of the method calls by adding the collation argument - Infact for good programming in general make this API your model, so if you were writing a shopping cart, this '.js' would provide methods like 'addToCart', 'removeFromCart', and all collations settings would be hidden in this layer and kept out of individual pages, whilst not needing to be stored in the database at all. Cheers, Keean. On 3 May 2011 15:27, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote: > On Tue, May 3, 2011 at 3:19 AM, Keean Schupke <keean@fry-it.com> wrote: > > The more I think about it, the more I want a user-specified comparison > > function. Efficiency should not be an issue here - the engines should > tweek > > the JIT compiler to fix any efficiency issues. Just let the user pass a > > closure (remember functions are first-class in JavaScript so this is not > a > > callback nor an event). > > Wouldn't it be a bit more complicated than just passing a regular > closure? The function has to be persisted in the database across page > views, but a JavaScript closure is going to contain references to all > sorts of objects (like document, or local variables) that are very > specific to the current page view. It makes no sense to persist those > objects in general. You'd need to serialize the function somehow, > possibly putting restrictions on the sorts of variables it can access, > so that it can be sensibly restored later. Is there some established > way of doing this yet in JavaScript? It might be useful in other > contexts too. > > I still agree that this is the correct direction to go in, though. >
Received on Tuesday, 3 May 2011 14:56:37 UTC