Here's the section on reserved words in the ES5.1 spec: http://www.ecma-international.org/ecma-262/5.1/#sec-7.6.1
And the same section in the ES6 / ES2015 spec: http://www.ecma-international.org/ecma-262/6.0/#sec-reserved-words The rule seems to hinge on whether something is an "identifier" or an "identifier name". It says that an "identifier" is any valid "identifier name", not including reserved words. I'm not an expert at reading language specs, so I can't find the places where the spec clearly shows that an "identifier name" is allowed. Mozilla's docs have a clearer explanation, though. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#Keywords Basically, in JS, it seems to boil down to places where you're allowed to optionally put quotes around something: 1. obj.identifierName 2. obj.indentifierName() 3. { identifierName: 2 } They could all be rewritten with quotes: 1. obj["identifierName"] 2. obj["indentifierName"] 3. { "identifierName": 2 } The Mozilla doc notes that this is not allowed, though: function identifierName() {} //error At first, I noticed similarity to member functions in AS3: class MyClass { public function identifierName() {} //is this considered the same as above? } However, the first one could be rewritten like this, where it's a variable, which must be an "identifier" instead of an "identifier name": var identifierName = function() {} //error because identifier names are not allowed! If classes are considered syntactic sugar for prototypes, then the AS3 version might be considered to be equivalent to this: MyClass.prototype.identifierName = function() {} We can rewrite that one with quotes, so the original sugar seems safe as an "identifier name", assuming that AS3 should follow the same logic. MyClass.prototype["identifierName"] = function() {} Anyway, just trying to wrap my head around it all. - Josh On Fri, Sep 18, 2015 at 2:03 PM, Alex Harui <aha...@adobe.com> wrote: > Josh, > > The key question here is whether is it is not valid AS3 per the language > spec, or whether the runtime and/or the compiler won’t let you compile it. > > AFAICT, what you want to do here is valid AS3 and I would expect the > runtime to run the expected ABC code, so it should be possible to get the > compiler to allow it. Where to look in the compiler code, I’m not sure. > My trick is to set a breakpoint on the CompilerProblem constructors and > look up the stack to see who decided it was time to generate an error and > why. > > One more scenario that I ran into today and haven’t tested on JS: > > I was porting the MXML feature test base class and to create AS feature > tests. It had: > var mxml:String = generateMXMLForTest(); > > Which I changed to: > var as:String = generateASForTest(); > > I would expect this to be valid in JS because “as” is not a keyword in JS. > It is interesting that you can’t do “var var” in JS or AS3, but since AS3 > has more keywords like that than JS, it is possible someone might have a > d.ts file with an API with an AS-only keyword in it and then I’m not sure > what to do there. In this case, though, I think it should be ok to have a > local variable names “as”. > > So, do we know in JS where keywords are and aren’t allowed? > > Can you do: > var in; > > Or: > > foo = function(in, out) > > We should probably get the big picture of where keywords are allowed > before making changes in this area. > > Thanks, > -Alex > > > On 9/18/15, 12:39 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: > > >JavaScript allows the use of reserved words as members of > >classes/interfaces, but AS3 does not. > > > >In JS and AS3, this is not valid: > > > >var var = 5; > > > >However, in JS, this is valid: > > > >var obj = {}; > >obj.var = 5; > > > >Not in AS3, though. > > > >Similarly, these are not valid AS3, but some JS types have methods with > >these exact names, so that needs to change: > > > >class Test > >{ > > public function delete():void {} > > public function continue():void {} > >} > > > >As far as I can tell, this JS behavior became valid in ES5. I assume after > >ES4 was cancelled. There are even some APIs in the JS standard library > >take > >advantage of this behavior already, and I'm sure that many JS libraries do > >too. > > > >Right now, to successfully build a standard library with externc (or my > >dts2as tool), these APIs need to be completely excluded. It's fine for a > >temporary workaround, but it will become an issue eventually. > > > >Alex, since you've been talking about compiler changes, I thought I'd > >throw > >this one into the ring too. > > > >(I'm not yet familiar with this part of the compiler, but if I knew where > >to look, I might be able to figure it out.) > > > >- Josh > >
