+1 to renaming the options to the positive.
On 5/6/19, 8:12 AM, "Josh Tynjala" <[email protected]> wrote:
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fimprovements%2FLanguage%2Fframeworks%2Fprojects%2Fpom.xml%23L88&data=02%7C01%7Caharui%40adobe.com%7Ce44a5f9a81b141a8414908d6d2352ee6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636927523209585267&sdata=ZDbgmmsdx4m6D9Bnel839Lxi4sVh8kwNLKK4HS%2F%2ByW8%3D&reserved=0
> ant:
>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fimprovements%2FLanguage%2Fframeworks%2Fjs%2Fprojects%2FBasicJS%2Fsrc%2Fmain%2Fconfig%2Fcompile-js-config.xml%23L106&data=02%7C01%7Caharui%40adobe.com%7Ce44a5f9a81b141a8414908d6d2352ee6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636927523209585267&sdata=kvr13pxvGktxjV7QLu0mWdKJZfpr3zk6AHCj%2FM74Ym4%3D&reserved=0
> )
>
>
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fblob%2Fimprovements%2FLanguage%2Fmanualtests%2FUnitTests%2Fsrc%2Fmain%2Froyale%2FflexUnitTests%2Flanguage%2FLanguageTesterTestVector.as%23L65&data=02%7C01%7Caharui%40adobe.com%7Ce44a5f9a81b141a8414908d6d2352ee6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636927523209585267&sdata=NNJ6cfAOqGHPya5oyADDhwBwkWpNkng%2Fk0%2BvrzZm7aM%3D&reserved=0
>
>
>
> *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.
>
