Hi Greg,
thanks for reporting. I can share here that I was able to test your branch
with our real project and seems all goes well.
Could make a intense test, but almost app is working and we found just a
few type error coercions that your code was able to catch (so great! :))
and must be solved as you merge the branch in.
I think that if Vector is something new and others don't have problems, the
branch can be merged and Vector discussions can be done after that, since
it will not break anything since there's no uses of that code since is new,
but the other changes can be very beneficial
thanks in advance for your progress in all this stuff :)
Carlos
El vie., 10 may. 2019 a las 8:44, Greg Dove (<greg.d...@gmail.com>)
escribió:
> All, I am really sorry, I keep thinking I will be able to get back to this,
> but I have some other personal things taking my spare time at the moment.
> These will be done in 2 days, and I then will update the branch with some
> extra stuff, and continue this discussion with a focus on Vector (bringing
> some other relevant discussion on the same topic from Alex as well) at that
> time. Sorry to set the wrong expectations earlier.
>
>
> On Tue, May 7, 2019 at 9:01 AM Greg Dove <greg.d...@gmail.com> wrote:
>
> > 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 <aha...@adobe.com.invalid>
> > wrote:
> >
> >> +1 to renaming the options to the positive.
> >>
> >> On 5/6/19, 8:12 AM, "Josh Tynjala" <joshtynj...@apache.org> 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 <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://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.
> >> >
> >>
> >>
> >>
>
--
Carlos Rovira
http://about.me/carlosrovira
