OK, well that made things “easier”. I’ve pushed changes with a few tests
into the JsToAs branch. Volunteers are welcome to add more tests for the
other keywords
Now the question is: Do we gamble and merge these changes into the
develop branch for the upcoming release?
-Alex
On 9/24/15, 9:15 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>Requiring "this." before a reserved word when it's used as the name of a
>member seems perfectly reasonable. It's sort of the same thing as when a
>function parameter is named the same as a member variable.
>
>function(param:String):void
>{
> this.param = param;
>}
>
>Sometimes, certain naming conflicts require you to use "this." to access
>what you want, and that's okay.
>
>- Josh
>
>On Thu, Sep 24, 2015 at 8:53 AM, Alex Harui <aha...@adobe.com> wrote:
>
>> Well, this is turning out to be trickier than I thought. I’m not a
>> language person, but one difficulty in getting this to work in our
>> compiler seems to have to do with a key difference between AS and JS.
>>
>> As Josh mentioned in the links below, in JS identifierNames can be used
>> essentially anywhere you can use bracket access. My current theory is
>> that this is allowed in JS because all identifierNames have to be
>>accessed
>> as obj.identifierName.
>>
>> But in AS, obj is assumed and that makes lexing and parsing difficult
>>in a
>> couple of situations. For example:
>>
>> JS:
>>
>> Foo = function() {};
>> Foo.prototype.return = function(someParam) {
>> };
>> Foo.prototype.test = function() {
>> this.return(10+20);
>> return (10+20);
>> };
>>
>> In the above example, I can create a function called “return” and call
>>it
>> with an expression as a parameter and then return an expression.
>>
>> But now look at the AS:
>>
>> class Foo
>> {
>> function return(someParam)
>> {
>> }
>> function test():int
>> {
>> return(10+20);
>> return (10+20);
>> }
>> }
>>
>> Because AS assumes ‘this’, I can’t think of a way to distinguish
>>between a
>> call to a function called “return” and the return keyword that returns
>>an
>> expression. Same for “catch” and probably “new” and maybe even “throw”.
>> I think this is why JS disallows keywords for local variable and local
>> function names.
>>
>> I think other keywords like “default” and “as” and “is” can be
>> distinguished from the token stream which can look back one token and
>> ahead a few tokens. I gave up trying to handle this on the parsing side
>> because the set of allowed tokens was going to greatly complicate the
>> grammar.
>>
>> My current plan is to “do the best we can” which means that there will
>>be
>> funky rules when using keywords in identifierNames. I think the only
>> other option is to simply disallow some keywords as identifierNames.
>>
>> So the funky rules are going to be things like:
>> 1. You can use “return” and “catch” as identifierNames but you must use
>> “this.” or some other “.” expression in order to access it.
>> 2. You can use “break” and “continue” as identifierNames but plain
>> “break;” is the keyword and not a call to the getter. Same for
>>“continue”;
>>
>> Thoughts?
>> -Alex
>>
>> On 9/22/15, 10:56 AM, "Alex Harui" <aha...@adobe.com> wrote:
>>
>> >I’m going to see what compiler changes are needed for this.
>> >
>> >-Alex
>> >
>> >On 9/18/15, 4:56 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>> >
>> >>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
>> >>>
>> >>>
>> >
>>
>>
