So... just an overview of recent work I have been doing. Summery up front, some extra detail further down... please try things with the branch if you have time.
In the *improvements/Language* branch there are many updates inside Language and related updates inside the compiler to address these main areas: -Fixes/better support for int and uint types at runtime -Fixes for strict equality comparisons when instantiated types are uncertain, or known to be problematic in these cases for specific types that are known. -Complex implicit coercions (throws errors if assigned type is incorrect) -Vectors - test-driven development of a conforming implementation. The new features are supported by almost 350 new assertion tests (in the UnitTests manualtests project). This was not a trivial amount of work :) I still have a few things to work on in the branch, including some tuning for the new configuration settings and adding tests to the compiler for those, but I would be keen for others to test the branch and try it with real projects, and provide feedback. So this is 'improvements/Language' for both royale-asjs and royale-compiler. In particular, please take Vector for a spin and see if you can break anything and let me know! Note the new configuration settings a bit further down (and see examples here for how to switch them off globally: mvn: https://github.com/apache/royale-asjs/blob/improvements/Language/frameworks/projects/pom.xml#L88 ant: https://github.com/apache/royale-asjs/blob/improvements/Language/frameworks/js/projects/BasicJS/src/main/config/compile-js-config.xml#L106 ) A couple of examples: I tried compiling Tour de Jewel with the new features switched on, it it immediately highlighted a runtime error where a 'bead' was being added which was not actually an IBead. This was detected in a Vector push operation. Although it was not causing problems, it is a good example of something that would have failed at runtime in the flash player, making it much easier to identify and fix. I have switched the extra outputs off for all the framework code in the branch. But I did try a couple of projects with them on. As an example, after building XML with them on it throws a runtime error when calling one of the methods in XML. The method has the wrong argument type (Element type when it should -iirc- be Node). So these can catch errors in your code that are silent because there is no strong typechecking at runtime. The above is the implicit complex coercion in action. it is like if you did in flash player : var myArray:Array = [new ByteArray()]; var sprite:Sprite = myArray[0]; //runtime error here This does not happen currently in Royale javascript, but is now supported in the branch (and you can switch it off). This is an expansion of some of Josh's great work in the past with implicit primitive coercions (which don't throw errors but coerce to the correct type). *New configuration settings* js-no-complex-implicit-coercions default: false (i.e. ensures runtime safety when assigning an unknown type to a known type ) local doc comment directive switching: @royalesuppresscompleximplicitcoercion js-no-resolve-uncertain default: false (i.e. ensures instances that are safe in certain comparisons ) local doc comment directive switching: @royalesuppressresolveuncertain js-no-vector-index-checks default: false (i.e. vector index checking is on) local doc comment directive switching: @royalesuppressvectorindexcheck *-Fixes problems/provides more general support for int and uint types at runtime* Josh's recent assignment implicit coercions made a big difference for these (and other primitive types), but runtime support either caused errors or bad results. Things like var myClass = int; var x:* = new myClass(22.5); trace( x === 22 ) //true The above works now in the branch. iirc I think there is more than one issue with that in develop. I started with this based on issue #273 which also now is fixed in the branch. int and uint are implemented are not needed like this in most cases, so the are not real 'classes' but very simple instances of 'synthetic Types' that are only 'created' if/when they are requested for the first time. Vectors (because they are kind of like factory-generated classes) use the same underlying mechanism, but are more complicated than int and uint in terms of their supporting implementation. uint and int are almost defined in a single line of code, not so for Vectors. Another candidate for a synthetic type might be 'Class', but I will see about that. *-Fixes for strict equality comparisons in when instantiated types are uncertain, or known to be problematic for types that are known.* Certain explicit instantiations of primitive types are swapped to coercions. Things like 'new String('test')' are now output simply as String('test'). Resolution of uncertain instantiations Where a class is not known, the instantiation of that class is wrapped in a 'resolveUncertain' method call. This calls the low level native 'valueOf()' method on the instance, which resolves it to primitive types if possible. The above changes provide consistency with AVM when values , even those with typing obscured, are used in strict equality comparisons. These cases may not bet mainstream, but that is exactly the type of thing the causes a lot of headscratching when things don't work. Note that Array.indexOf also uses strict equality comparisons, so this is not just fixing results of === or !== across these edge cases. *-Complex implicit coercions* I expanded on Josh's implicit primitive type coercions to support more complex coercions (this is on by default, but explicitly off in the framework) So this works now like flash player: var myClass:MyClass = someArray[i]; //if the assigned value from someArray[i] is not a MyClass type, error is thrown This can be switched off at compiler level, or tuned within methods (on or off in contrast to compiler level setting) with a specific doc comment directive. (i.e. like royaleignorecoercion) Output in debug mode shows these implicit coercions prefixed with /* implicit cast */ so you can easily review the number of locations this is affecting by doing 'find in files' and looking at the locations and count. While it will probably be a good thing to switch off in a final release build, it can help find problems during development, particularly as more and more code is not being parallel tested in the flash player where error trapping like this is automatic. I switched this off in framework, but it could help find code errors in the framework when it is switched on *-Vectors* Vectors are 'smoke and mirrors' currently in develop - it is basically the compiler pretending that they are Vectors (they are Arrays). This gives a small amount of compile time safety, but still leaves large gaps when compared with the real thing and many things that you could assume would be safe will not be. Assuming it worked properly could be even considered a little 'dangerous'. There are 260 new assertion tests for Vectors, including some that relate to a new doc comment directive @suppressvectorindexchecking which avoids (intensive) checking for range errrors (and will be desirable to switch off in a lot of cases, such as in length constrained loops etc). You can see the Vector tests here: https://github.com/apache/royale-asjs/blob/improvements/Language/manualtests/UnitTests/src/main/royale/flexUnitTests/language/LanguageTesterTestVector.as#L65 *Miscellaneous* -When addressing some sourcemap related stuff for Vectors, I fixed an unrelated sourcemap issue that was caused by methods which had metadata attached. The mapping now correctly aligns with the original function keyword in these cases.
