Harbs, thanks for your interest. I'd echo Carlos' comments about there being more details in the earlier stuff. I know its long, but parts of it are an information dump of learnings, and other parts are why I did things the way I did.
Some other quick comments: "The goal of these changes are to enforce *runtime* Vector type safety? As far as I understood, *compile time* safety was already being enforced." Yes. But compiletime safety is only available on parts of the Vector api because of the method signatures, in fact the as3 docs specify this explicitly for some methods. Those methods (like push for example) only have runtime safety. If you use index level assignments you should get compile time safety for complex types. And because Josh added primitive type coercions that part is good if you assign a string value to an int Vector for example. This branch also has support for implicit complex type coercions as well - which is not specific to Vectors - but which will in javascript throw an error just like in flash if there is something wrong. (easily switchable off, and is off in the framework projects) And of course you also have things like IDE driven completion for pop() method etc "You say there shouldn’t be runtime performance hits? How did you manage that?" It is still an Array, but just one that is 'enhanced', so whereever possible it can still fall back to native speed. Construction will be slower than array, but I don't expect it will be much different to construction of a regular class. And I think most Vector code is about loops and content rather than making lots of Vectors. They following should be able to work at 100% speed or very close to it: pop() shift() index access index assignment (with @suppressvectorindexcheck Most other methods will be slower, but they do now have conforming runtime type safety. This includes Vector-of-Vector types etc. "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" Outputting as Array was a non-implementation/placeholder. If we get comfortable with a non-implementation then I think that is a reluctance to do the right thing. The problem with it is that it is not what the actionscript language specifies, but the compiler always thinks it is. If someone released library code which had some Array only implementation, it would still say it was a Vector in terms of type but it would not behave like one if passed around to other parts of code that may want to use it. And as/is type checks are all messed up. However I do want to work on a separate cross-target solution which focuses on the fastest implementations for the 3 numeric types which is where the Vector speed up is in flash - and is also how and why I mostly used them in flash too. My intention with that will be essentially expose the functionality of javascript TypeArrays to both targets via a common class, and this therefore ought to be faster than 'Array' in javascript too (I fully expect it to be, but I have not specifically tested it). And no, it would not use getItemAt/setItemAt - if I can implement how I plan to, it would be regular full speed index access. I think I can work with that approach for high speed numeric collections - do you think that would meet most of your own needs if it only worked with pre-allocated sizes and only via index access? (i.e. no push/pop etc) - essentially like the fastest flash Vector configuration, a fixed=true Vector ? I think making it more Vector like in terms of api would be possible, but it will be heavier and also slower (because fixed length is the faster configuration). "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." I am not proposing new syntax or anything like that. I think that is something for the future :) On Sun, May 26, 2019 at 10:53 PM Carlos Rovira <carlosrov...@apache.org> wrote: > 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 (<harbs.li...@gmail.com>) > 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 <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. > > >> > > >> > > > > > > -- > Carlos Rovira > http://about.me/carlosrovira >
