RE: Seeking pre-LCWD comments for Indexed Database API; deadline February 2

From: Jonas Sicking [mailto:jonas@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

Received on Tuesday, 15 June 2010 06:21:41 UTC