royale-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] hcsuk opened a new pull request #56: Fixing bug with static function resolution
Date Mon, 05 Nov 2018 15:04:14 GMT
hcsuk opened a new pull request #56: Fixing bug with static function resolution
URL: https://github.com/apache/royale-compiler/pull/56
 
 
   Ensures the initial class scope is at the top of the stack so that it is popped first;
allows overriding of `apply` and `call` etc where these are present in the scope stack due
to Class deriving from Function
   
   I had noticed that I kept on getting errors when transpiling code that used `ExternalInterface.call`,
where the JavaScript ended up just as:
   ```
   ExternalInterface.call("MyMethod");
   ```
   rather than the calls to `ExternalInterface.available` or `addCallback`, which were correctly
emitted as:
   ```
   mx.external.ExternalInterface.addCallback("fncName", myCalback);
   ```
   
   Having looked into this, there's a scope resolution where the compiler is looking for a
definition of "call" within the current scope - at the top of which is the ExternalInterface
class, and it should then expand the search to the base classes. As a static type, the base
of ExternalInterface is Class, the base of Class is Function, and the base of Function is
Object. However, in the `StaticTypeIterator` initilalizer, the code was adding the initial
scope (ExternalInterface) to the stack and then adding the built-in Class definition; this
is the wrong order, since the iterator's `next` method pops the most recent addition first.
   
   So to correct this, we push the `Class` type and then the `initialType` (ExternalInterface
in my case) is added on top. Note the "skipThis" flag which affected the behaviour; checking
for this here simplifies it a little bit, as the flag (if used?) indicates that the initialType
should be ignored and would have been added to the visited list rather than onto our stack.
The old implementation of this - just calling `next()` if `skipThis` was true - would have
exposed the bug, as the call to `next()` would have removed the Class definition...
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message