On 4 May 2011 00:57, Jonas Sicking <jo...@sicking.cc> wrote: > On Tue, May 3, 2011 at 12:19 AM, Keean Schupke <ke...@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). > > I don't think we should do callbacks for the first version of > javascript. It gets very messy since we can't rely on that the script > function will be returning stable values. >
garbage in = garbage out. The programmers job is to write a correct comparison function. All functions have this problem. By this argument we had all better give up programming because there is a risk we may write a function that returns incorrect results. > Additionally we'd either have to ask that the callback function is > re-registered each time the database is opened, or somehow store a > I still think re-registering is a non-issue. It is trivial to declare a local open function "openNameIndex" than calls "openIndex" with the correct callback and provide that as a software-module - either in the main code, or in a separate JS file that can be included in each page. Modular programming is a good thing, should be encouraged, and is the traditional software engineering solution to this kind of problem. serialized copy of the callback function in the browser so that it's > available the next time the database is opened. Neither of these > things have been done in other APIs in the past, so if we hold up v1 > until we solve the challenges involved I think it will delay the > release of a stable spec. > > So the choice here really is between only supporting some form of > binary sorting, or supporting a built-in set of collations. Anything > else will have to wait for version 2 in my opinion. > > / Jonas > Cheers, Keean.
