- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 11 Jun 2010 15:19:30 -0700
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Pablo Castro <Pablo.Castro@microsoft.com>, Kris Zyp <kris@sitepen.com>, WebApps WG <public-webapps@w3.org>
On Fri, Jun 11, 2010 at 2:05 PM, Jeremy Orlow <jorlow@chromium.org> wrote: > On Fri, Jun 11, 2010 at 9:52 PM, Pablo Castro <Pablo.Castro@microsoft.com> > wrote: >> >> From: jorlow@google.com [mailto:jorlow@google.com] On Behalf Of Jeremy >> Orlow >> Sent: Friday, June 11, 2010 3:20 AM >> Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline >> February 2 >> >> On Fri, Jun 11, 2010 at 1:54 AM, Pablo Castro <Pablo.Castro@microsoft.com> >> wrote: >> >> >> From: Kris Zyp [mailto:kris@sitepen.com] >> Sent: Thursday, June 10, 2010 4:38 PM >> Subject: Re: Seeking pre-LCWD comments for Indexed Database API; deadline >> February 2 >> >> >> >> 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. >> >> 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. / Jonas
Received on Friday, 11 June 2010 22:20:23 UTC