I read through this, but I might be missing the background. I’ve missed quite a few discussions on the list lately. (Life has been busy…)
Can you summarize what you were working on fixing in Vector? Thanks, Harbs > On May 5, 2019, at 11:00 AM, Greg Dove <greg.d...@gmail.com> wrote: > > 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.
