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
