Hi Harbs, for performance explanation I think there's all explained in his long email in this thread. I think you should read that since there's many info, included new compiler options and more. It takes a bit of time, but I think it's worth it.
thanks El dom., 26 may. 2019 a las 12:47, Harbs (<[email protected]>) escribió: > 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 <[email protected]> wrote: > > > > Hi Harbs, a real quick answer inline below. > > > > > > On Sun, 26 May 2019, 20:39 Harbs, <[email protected]> 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 <[email protected]> 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. > >> > >> > > -- Carlos Rovira http://about.me/carlosrovira
