Let me know if I understand correctly. The goal of these changes are to enforce *runtime* Vector type safety? As far as I understood, *compile time* safety was already being enforced.
You say there shouldn’t be runtime performance hits? How did you manage that? Is this going to be a compiler option? Most of my use of Vector in Flash was to speed up arrays. Second to that was compile time type safety. Runtime type safety was much less important to me. Personally, I’d like to be able to use `int[]` and `MyFoo[]` for typed arrays instead of Vectors for the vast majority of my Vector uses. Thanks, Harbs > On May 26, 2019, at 12:59 PM, Greg Dove <greg.d...@gmail.com> wrote: > > Hi Harbs, a real quick answer inline below. > > > On Sun, 26 May 2019, 20:39 Harbs, <harbs.li...@gmail.com> wrote: > >> 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? >> > > In a word: parity. Vector did not have an actual real implementation. The > compiler is essentially outputting a normal regular Array in develop. So > distinctive Vector type safety features do not work in develop and runtime > is/as type checks and coercions etc don't behave the same in js as swf. All > that is addressed in the branch. > > > >> 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. >> >>
