Thanks for the feedback, Josh, Carlos, Alex.
js-complex-implicit-coercions
js-resolve-uncertain
js-vector-index-checks
I will make those changes for compiler settings at some point in the branch
later today, invert the config default values to match, and swap all 'off'
settings in the framework builds (ant and maven) from true to false.
I will also add compiler tests for these settings (either today or
tomorrow). At the moment I only tested the new settings in the code result
tests in javascript.
In another day or two I will post a call to discuss the Vector
implementation in more detail. For Vectors, the js-vector-index-checks was
the obvious first candidate for dialing back on the impact of runtime
type-checking, but there are a number of options for 'dialing' other
aspects back (or even forward) and choosing the scope of their effect
(local code, local project, or entire codebase code including external
swcs). I already had stub code for the start of something else to remove
typechecking in mutation methods ('push', 'shift', 'pop' etc) but removed
it in favour of discussing and reviewing it first. Coming up with a
'usable' set of options will really benefit from your collective input, so
I hope you can participate.
On Tue, May 7, 2019 at 4:19 AM Alex Harui <[email protected]> wrote:
> +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.
> >
>
>
>
