Hi, I must say that I use to have problems with the same, I think that renaming will be good for usability
El lun., 6 may. 2019 a las 17:11, Josh Tynjala (<[email protected]>) escribió: > Hey Greg, > > I haven't had a chance to look through all of the changes, but one thing > caught my eye. I find it confusing when a boolean value is named with a > "negative" phrase. For instance, your new compiler options have "no" in the > name: > > js-no-complex-implicit-coercions > js-no-resolve-uncertain > js-no-vector-index-checks > > As they are named, true means no, and so false means yes. With this kind > of naming, I find that I always need to take a moment to remember which > means which. I think it would be better if true means yes and false means > no. > > - Josh > > On 2019/05/05 08:00:20, 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
