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

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