Hi, (brief background before jumping out of the blue: I'm working with Andrei and Jeremy with the IDB implementation..)
I'd like to mention the IDBCursor::continue is also problematic, as afaict "continue" is a reserved keyword in JS? oh, "delete" seems to be reserved as well: https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Reserved_Words Not sure what to suggest though, perhaps "move()" ? We can't have "next()", since the cursor is opened with a direction.. thoughts? Thanks, Marcus On Tue, Jun 15, 2010 at 7:20 AM, Pablo Castro <pablo.cas...@microsoft.com> wrote: > > From: Jonas Sicking [mailto:jo...@sicking.cc] > Sent: Friday, June 11, 2010 3:20 PM > >>> >> >> So there is a real likelyhood of a browser implementation that >>> >> >> will predate it's associated JS engine's upgrade to ES5? >>> >> >> Feeling a "concern" isn't really much of technical argument on >>> >> >> it's own, and designing for outdated technology is a poor approach. >>> >> I don't think there is, just wanted to avoid imposing it. If you >>> >> think it's really important then let's change it back to delete >>> >> assuming other folks are good with it. >>> >>> >> I had the same concerns Pablo did, but I don't feel strongly >>> >> either way. > > Besides the maneuvering we'll have to do on the C++ side of things to avoid > clashes with language keywords, the question is whether we expect plugins and > such to add support for IndexedDB in existing browsers that don't do ES5. For > example: > http://code.google.com/p/firebreath/wiki/FireBreathUsers > >>> >>> Before we close on this, let me validate one more thing independently >>> of the JS version. Are we going to have trouble when trying to expose >>> these interfaces in C++? Not sure about other compilers and IDL >>> processing tools, but I'm playing around with Visual Studio 2010 and >>> while the COM IDL compiler will take "delete" as an interface member, >>> my C++ compiler really doesn't like it. As far as I know there is no >>> standard syntax to indicate that a symbol wasn't meant to be a >>> keyword in C++, so having "delete" (or other C++ keywords for that >>> matter) would be problematic. Am I missing something? >> >> Good point. Does anyone have a strong opinion on how much we should >> care about reserved word conflicts in language other than JavaScript? >> it seems like a slippery slope. >> As an example, "IDBDatabase.description" is actually used by the >> ObjectiveC base object class and so this caused some problems >> initially. We worked around it by having the ObjectiveC bindings >> generator add a suffix whenever an attribute named "description" is >> hit. (Something similar was done for "hash" and "id" in other APIs.) >> To be honest, I hadn't even considered bringing this up and asking for >> it to be changed, but if we're going to avoid delete because it's a >> reserved word in JavaScript (pre v5) and/or because it's a reserved >> word in C++, perhaps we should consider changing description as well? > >>> We've had to do this a few times in the past already. One example was >>> Window.postMessage where we couldn't use the name "PostMessage" in C++ >>> because it was a predefined macro on some platform (windows iirc, not to >>> point fingers ;) ). > > :) > >>> We developed a similar trick where we can indicate in the IDL that >>> different names are used for scripted languages and for compiled languages. > >>> So all in all I believe this problem can be overcome. I prefer to focus on >>> making the JS API be the best it can be, and let other languages take a >>> back seat. As long as it's solvable without too much of an issue (such as >>> large performance penalties) in other languages. > > I agree we can sort this out and certainly limitations on the implementation > language shouldn't surface here. The issue is more whether folks care about a > C++ binding (or some other language with a similar issue) where we'll have to > have a different name for this method. > > Even though I've been bringing this up I'm ok with keeping delete(), I just > want to make sure we understand all the implications that come with that.. > > -pablo > > >
