You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Greg Dove <gr...@gmail.com> on 2019/05/05 08:00:20 UTC
Language improvements
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.
Re: Language improvements
Posted by Carlos Rovira <ca...@apache.org>.
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 (<jo...@apache.org>)
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 <gr...@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
Re: Language improvements
Posted by Piotr Zarzycki <pi...@gmail.com>.
Alex,
I don't understand about what PAYG implementation we are talking about in
case of vector. What can be choosen and what cannot in case of that entity?
It's like Carlos said to me Vector is like another type Number, String etc.
Thanks,
Piotr
On Sun, May 26, 2019, 9:04 AM Carlos Rovira <ca...@apache.org> wrote:
> Hi Alex,
>
> I think PAYG is very important to all of us. And I'm with you that PAYG is
> itself more important than the fact that a small Kbs incrementation (as a
> concept itself). We always have it in mind. But in this concrete case, I
> think Vector is part of the AS3 base and Greg have a first implementation
> for it. For me is like to have String, Number, Date...
>
> So, nothing stops Greg, you or others to continue evolving it to improve
> PAYG in this implementation, but that should happen IMHO after we have this
> one, Since that will not happen any time soon. And better to have something
> than nothing.
>
> In the other hand, maybe in this concrete case discussion over Vector and
> PAYG could derive in community be happy with current implementation or
> wanting more options.
> People will need time to work and experiment with this implementation and
> could report they are happy or they find problems.
>
> Or people can report they want other kind of implementation, in case that
> will be a great point to make it more PAYG (although always that will
> requiere the time, knowledge and effort to make it happen).
>
> What I want to expose is that we should embrace this new implementation as
> the step one, and progress from there to other status little by little
> since sometimes trying to reach to the maximum goal we have in mind could
> be very expensive in terms of time, effort and will left us with the
> possibility to have today the feature, while if we do little by little, we
> have both, the feature and the possibility to continue improving it to be
> better (in this case the possibility to be more PAYG). Perfection is enemy
> of progress.
>
> ITOH, that will be great too since the natural process could make this
> implementation will be chosen by community as something final...or
> not....so for me, let's merge it, since is good and is a great step
> forward, and then continue discussing it to see next steps. The later could
> make this evolve more or not...what is clear is that will be weeks or
> months ahead. That's what we've done with many other features in Royale,
> some of them still in progress (Jewel, themes, compoenents,...)
>
> People could want choices or not, but current branch will give all of us a
> first choice since we have 0 right now. Then we can move to convert this on
> multi-choice if community want it, and chances are that people is not
> interested in that...or not...we should see.
>
>
>
>
> El dom., 26 may. 2019 a las 1:10, Alex Harui (<ah...@adobe.com.invalid>)
> escribió:
>
> > Hi Greg,
> >
> > Thanks for working through all of this. Better Vector handling is
> > definitely a good thing for Royale.
> >
> > However, IMO, PAYG is more important and 3KB can be a full second or more
> > on busy/slow/poor networks. As such, folks need to have choices. So as
> > long as folks can choose Vector implementations we should be good.
> >
> > Flex failed in some major vendors' customer-facing apps because of
> > download times. I have spent the past years trying to make sure Royale
> > does not repeat those mistakes.
> >
> > I have some comments on finer details, but let's see if we can agree on
> > this higher-level issue first. We simply should offer people choices.
> >
> > Thanks,
> > -Alex
> >
> > On 5/25/19, 2:45 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >
> > Hi Carlos, thanks for your feedback. In terms of PAYG, I just have a
> > sense
> > that at the language level, the 'default' should be that it *works*
> as
> > per
> > design.
> > If I take the example of Vector... then numeric Vector types will not
> > run
> > faster in javascript. Using all the method calls will have a
> > substantial
> > impact compared to using a normal Array. But code should 'work' the
> > same
> > across targets.
> > I do have some ideas for application framework classes outside
> > 'language'/Vector that would provide target-agnostic fast regular
> class
> > implementations for numeric typed Arrays, and I hope to work on that
> > soon
> > as well, which takes more advantage of the optimized native options
> on
> > each
> > target (Vector in swf, TypedArray in javascript). But to achieve that
> > it
> > will likely be 'always fixed length' in this case, I will see if it
> > seems
> > worth trying to be able to toggle that, or maybe it can be a bead or
> > opt-in
> > support to get that functionality. But that should provide a good
> > option
> > for developers seeking to get the best performance for numeric
> > collections.
> > I expect to work on this during June.
> > Or developers can of course always choose to implement their own
> custom
> > performance code in COMPILE::JS / COMPILE::SWF variations, which is
> > always
> > an option.
> >
> >
> > Hi Piotr, sorry about that email formatting issue. Thanks for your
> > follow
> > up on this.
> > Here is a paste of that part, which includes the code.
> >
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdPWy&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212062967&sdata=17ke54YZccaT%2BCQNKJLeihpTrSb2Nf4JB37o6c4ozGs%3D&reserved=0
> >
> > Also, if you want to see the tests for Vector, you can see them 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&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=GbM8oh6UkKpVE2HsdKwHgt6RgRJ9iNWIlCAhiubmHTk%3D&reserved=0
> >
> >
> > You should see large parts of that series of tests fail outside the
> > branch, and in some cases there were compiler errors too iirc (or
> > maybe I
> > am confusing some compiler fixes I did for other things, can't be
> sure
> > now)
> >
> >
> >
> > On Sun, May 26, 2019 at 4:58 AM Carlos Rovira <
> carlosrovira@apache.org
> > >
> > wrote:
> >
> > > Hi!
> > >
> > > Read it! :), was long but I think this emails are needed since it
> > brings
> > > many thoughts that only the developer knows and otherwise would end
> > never
> > > known by the rest of the community. So Great!
> > >
> > > Greg, first, many thanks for working on this. I think we get other
> > point
> > > solved, and I think not only Vector, but many other fixes and
> things
> > coming
> > > in your branch.
> > >
> > > For my part, as you said, the branch is tested against my real
> > project,
> > > that I think is a very good way to test against lots of working
> > code. So
> > > for my is ok to merge, not only cause it does not brake anything,
> > but cause
> > > it's a big step forward.
> > >
> > > Since it brings things we didn't have before like Vector, is good
> to
> > bring
> > > this. Then we can continue iterating to add missed things like AMF
> > support
> > > or to evolve to other state or even change internal things if other
> > check
> > > and see ways of enhancements.
> > >
> > > About the Vector implementation. My opinion is that I think as you
> > that
> > > Vector is an intrinsic part of AS3, so better to have an
> > implementation to
> > > complete AS3 in Royale. About having multiple implementations, I
> > think that
> > > could be good in the future if things can be done that way, but
> > better
> > > start from this starting point and see what happens in next
> > months-years.
> > > IOW, better have a real implementation now that a potentially one
> > that
> > > still is not here. We need to see the goal and approach to it
> > progressively
> > > or we end getting nothing since the goal is a huge one not easy to
> > reach.
> > >
> > > For me the 3kb is totally normal, and as well a great achievement
> of
> > your
> > > implementation.
> > > I must say that my way of thinking in Royale is to be totally
> > aligned with
> > > concepts like PAYG, but sometimes we need to break rules when the
> > goal
> > > demand it, or we can end trying to apply the same principle to all
> > things,
> > > when sometimes is not the best. So this is importante, rules are
> > really
> > > good, but we need to always put behind a layer of human thinking
> > about what
> > > we are trying to accomplish
> > >
> > > Thanks Greg for reaching another important milestone! Amazing work!
> > :)
> > >
> > > Carlos
> > >
> > > PD: Piotr, about gmail cutting the email, I'm using gmail and get
> to
> > read
> > > it completely, maybe could be a problem of gmail in mobile? I'm
> > reading on
> > > gmail desktop. The only problem I had was reading posted source
> > code, but
> > > since it was tiny, I could finally read it...
> > >
> > >
> > >
> > >
> > >
> > > El sáb., 25 may. 2019 a las 15:37, Piotr Zarzycki (<
> > > piotrzarzycki21@gmail.com>) escribió:
> > >
> > > > Hi Greg,
> > > >
> > > > Could you please post the code from this email in the
> > paste.apache.org -
> > > > right now is unreadable in my Gmail account.
> > > >
> > > > Thanks,
> > > > Piotr
> > > >
> > > > On Sat, May 25, 2019, 4:51 AM Greg Dove <gr...@gmail.com>
> > wrote:
> > > >
> > > > > OK, At the risk of making what follows even longer... a
> warning:
> > *this
> > > > is a
> > > > > long read*. It might veer off topic in one or two places, but
> it
> > is
> > > > mostly
> > > > > about why, and how Vector is implemented the way it is in the
> > branch.
> > > > > Basically I would like to merge this branch into develop as
> soon
> > as
> > > > > possible, i actually think it is ready as is, but I am keen to
> > get
> > > other
> > > > > input before I do.
> > > > > Read it if you're interested. If you're not interested in
> > reading it
> > > then
> > > > > please try the branch on any 'real' projects that you have in
> > play.
> > > > Carlos
> > > > > has tested against his, and there are no issues, but it would
> be
> > good
> > > to
> > > > > get wider input.
> > > > >
> > > > > now to the textual onslaught:
> > > > >
> > > > >
> > > > > *Vector*
> > > > >
> > > > > One of the things I did before I worked on this Vector
> > implementation
> > > was
> > > > > to detach myself from ‘how I use Vector when I code’, to take a
> > step
> > > back
> > > > > and challenge myself to rethink how I thought about it in
> > general.
> > > > >
> > > > > Vector is *special*. Vector is not *a class* in a typical
> sense.
> > It is
> > > > the
> > > > > closest thing that as3 has to generics which, when used at a
> > class
> > > > level, I
> > > > > like to think of as the ability to generate multiple class
> > variations
> > > > from
> > > > > a single class definition (that is just the way I think of
> > them). So,
> > > at
> > > > > some level Vector could be considered as an infinite set of
> > distinct
> > > > > classes, based on an infinite set of possible specified element
> > types
> > > > > (whatever you see between the angle brackets in code). It is
> not
> > > actually
> > > > > implemented natively in AVM this way iiuc, but that is the
> > outward
> > > > > appearance, and that is also the behaviour it has when using
> type
> > > > checking
> > > > > in as3.
> > > > >
> > > > > Aside from the runtime typesafe behaviour, Vector’s strong
> > typing means
> > > > > there is additional compile time support and, related, the
> > possibility
> > > of
> > > > > extra IDE support, both of which help the developer.
> > > > >
> > > > > Vector ‘types’ are also final ‘classes’ enforced by the
> > compiler, so
> > > > cannot
> > > > > be extended.
> > > > >
> > > > > Additionally, on looking closer, there are some other quirky
> > rules for
> > > > > runtime typing behaviour. These are related to the
> > implementation in
> > > AVM.
> > > > > The 3 Vector types for Vector.<int>, Vector.<uint>, and
> > Vector.<Number>
> > > > are
> > > > > individual base types, and then there is a 4th base type,
> > Vector.<*>
> > > > which
> > > > > serves as the ‘base class’ of all other Vector ‘subclasses’.
> The
> > 3
> > > > numeric
> > > > > types are faster than Array, and I expect this was the reason
> > for the
> > > > > separation, because these are used in a lot of other flash
> apis,
> > > > > particularly for swapping with byte level data and things like
> > > BitmapData
> > > > > etc. The others are more simply for the strong typing aspects,
> > because
> > > > > (perhaps less so with Boolean and String at a guess) they are
> > somewhat
> > > > > slower than Array in AVM, because of the overhead of runtime
> > > typechecking
> > > > > and coercions etc. So the main selling points for choosing a
> > Vector in
> > > > > flash were a) compile time and runtime type safety and b)
> faster
> > > > > performance for the 3 numeric Vector types.
> > > > >
> > > > > One implication of these ‘rules’ means that to check if
> > *something* is
> > > a
> > > > > Vector of any type in swf, I need to do (mything is
> Vector.<int>
> > ||
> > > > myThing
> > > > > is Vector.<uint> || myThing is Vector.<Number> || myThing is
> > > Vector.<*>)
> > > > or
> > > > > use reflection (which is slower).
> > > > >
> > > > > The above implies that, for language conformance (considered as
> > > > conformance
> > > > > with as3 documentation/spec and the behaviour of the reference
> > > > > implementation that we have for any ‘unknowns’) in an
> emulation,
> > a
> > > > regular
> > > > > single as3 class implementation would not create a result that
> is
> > > > > consistent with the spec in terms of its representation of
> > typing, and
> > > > its
> > > > > behaviour when using type checking.
> > > > >
> > > > > I tried to take all of these things into consideration.
> > > > >
> > > > >
> > > > >
> > > > > *How is it implemented in the branch?*
> > > > >
> > > > > Vector is implemented using the lightweight ‘synthType’
> approach
> > I
> > > added
> > > > > previously to support for int and uint types as ‘classes’. This
> > > provides
> > > > a
> > > > > light integration for ‘is’ and ‘as’ checks, but in javascript
> > itself a
> > > > > Vector instance is simply a tagged native javascript Array
> > instance
> > > (i.e.
> > > > > an Array with something that identifies it as being ‘not a
> > regular
> > > > Array’).
> > > > > The Array methods are enhanced at the instance level to support
> > the
> > > type
> > > > > coercions that take place in an actionscript Vector. Using
> Array
> > makes
> > > > > sense because Vector instances are essentially typed Arrays.
> But
> > it is
> > > > not
> > > > > possible to extend Array in javascript and have things work
> > properly
> > > (it
> > > > is
> > > > > possible to use a different approach with es6 Proxy, but that
> is
> > not
> > > > > available in IE11).
> > > > >
> > > > > This implementation also means that a ‘Vector’ instance should
> > have
> > > > > functionality that works mostly as expected if it is passed
> > directly to
> > > > a 3
> > > > > rd party native javascript library that is expecting an Array
> > instance.
> > > > It
> > > > > will not support errors when changing the length if the Vector
> > instance
> > > > is
> > > > > ‘fixed’ length, for example but otherwise it should function
> > much the
> > > > same
> > > > > as a regular Array in the 3rd party code.
> > > > >
> > > > > The ‘synthType’ approach can be used because Vector types are
> > final, so
> > > > it
> > > > > does not need to conform to a regular Royale class definition
> > that can
> > > be
> > > > > extended and can be much ‘lighter’. As with int and uint
> > ‘classes’, no
> > > > > Vector constructor exists until the first one is requested.
> > There is
> > > one
> > > > > internal private class in Language that provides most of the
> > > > functionality
> > > > > for Vector, and element coercion functions are generated
> > specifically
> > > for
> > > > > each Vector ‘subtype’. Overall, it behaves more like a subclass
> > > ‘factory’
> > > > > with each individual type’s constructor being created on demand
> > and
> > > > cached
> > > > > for future use.
> > > > >
> > > > > Reflection and serialization support have not been added yet,
> > but I
> > > > > certainly had these in mind also with this approach. I just
> > wanted to
> > > > reach
> > > > > a sensible intermediate point for now, and then add those in
> > later.
> > > > >
> > > > > In summary, the Vector implementation in the branch provides
> the
> > > > following:
> > > > >
> > > > > -distinct types (conforming in terms of type checking) for each
> > Vector
> > > > > subtype
> > > > >
> > > > > -lightweight integration with Language ‘is’ and ‘as’ support
> > > > >
> > > > > -each Vector subtype has a unique constructor generated the
> > first time
> > > it
> > > > > is requested, the constructor does not exist prior to that.
> > > > >
> > > > > -expected to be compatible with 3rd party native javascript
> that
> > > expects
> > > > a
> > > > > regular javascript Array
> > > > >
> > > > > -serialization (amf) and reflection are not yet supported but
> > were
> > > > > considered, and that is planned as next steps.
> > > > >
> > > > > As at the time of writing, the current implementation is
> > supported by
> > > 300
> > > > > Vector-specific assertions that run side-by-side between
> > javascript and
> > > > swf
> > > > > in the manualtest UnitTests project. Apart from the differences
> > created
> > > > by
> > > > > explicitly switching off some type safety checks with
> > > > > @suppressvectorindexchecking, there is only one verifiable
> > difference
> > > in
> > > > > these tests between swf and javsacript. Probably there are
> things
> > > outside
> > > > > the test coverage that might need addressing still, but I think
> > it’s a
> > > > > pretty good start.
> > > > >
> > > > > These tests should be easily ported to framework level unit
> tests
> > > > > (RoyaleUnit) as the same approach has been used to add FlexUnit
> > tests
> > > in
> > > > > the past. Testing/Development is primarily in Chrome on
> windows,
> > but
> > > the
> > > > > same tests were subsequently verified on IE11, Edge, Opera and
> > Firefox
> > > on
> > > > > windows.
> > > > >
> > > > > *Implementation Info*
> > > > >
> > > > > *More quirks*
> > > > >
> > > > > A ‘fixed == true’ Vector cannot have its length changed. This
> > means
> > > that
> > > > > changes via the length setter and the mutation methods (push,
> > pop,
> > > shift,
> > > > > unshift etc) all throw errors if used when a Vector is ‘fixed
> ==
> > true’.
> > > > > But… splice method also can change length. And in AVM this
> works
> > even
> > > > with
> > > > > a fixed length Vector, which might possibly be a bug but is one
> > that is
> > > > > matched in the implementation to conform with flash.
> > > > >
> > > > > *Size impact.*
> > > > >
> > > > > Alex was concerned with size impact for HelloWorld because the
> > beads
> > > were
> > > > > using a Vector.<IBead> type in javascript in one of the
> > application
> > > > > framework base classes. But the requirement was for that to
> > simply to
> > > be
> > > > an
> > > > > Array in javascript, the compiler was only achieving that by
> > default
> > > > > because there was no real Vector implementation. So I did a
> > couple of
> > > > > things here. Firstly I changed the application framework code
> to
> > > reflect
> > > > > the different requirement for javascript. Secondly, I added
> some
> > doc
> > > > > comment directives to suppress exporting on public members.
> Then
> > I
> > > added
> > > > > this to the Language methods that are for compiler-generated
> > Vector
> > > (and
> > > > > int and uint) support so that they are eligible for dead code
> > > elimination
> > > > > if not used. This effectively means that it is fully PAYG – it
> > is only
> > > > > there if you need it, but if you need it there is also no
> effort
> > to add
> > > > it
> > > > > in as an optional dependency. If, because of this, there is a
> > potential
> > > > for
> > > > > issues with modules or something I have not thought of, that
> > will be
> > > > > another thing to solve, but if so, I will find a way to address
> > it.
> > > > >
> > > > > If the main concern with ‘size’ is data transfer, then looking
> > at the
> > > > > minified output size in HelloWorld is not really meaningful (or
> > perhaps
> > > > it
> > > > > is better to say that it is only as meaningful as looking at
> the
> > size
> > > of
> > > > an
> > > > > uncompressed swf compared to normal deployment of a compressed
> > swf). In
> > > > any
> > > > > real deployment the javascript should be served as gzipped. So
> I
> > > compared
> > > > > gzipped (‘normal’ compression) versions of HelloWorld.js
> between
> > those
> > > > with
> > > > > the unused Language support methods (for int/uint and Vector)
> > and their
> > > > > dependencies vs. builds without. The support for all that
> > functionality
> > > > > comes in at under 3 Kb difference in the gzipped output. I
> > personally
> > > > don’t
> > > > > think that would register as important in most cases. However,
> > it is
> > > > pretty
> > > > > close to zero impact now if it is not used. In fact the
> > HelloWorld
> > > > > application is now about 55 bytes smaller than it was before,
> so
> > I
> > > > consider
> > > > > it ‘carbon-netural’. And these are at the gzipped levels (it is
> > also
> > > > > slightly smaller when not gzipped, although it can sometimes be
> > the
> > > case
> > > > > that the larger of 2 files compresses better than a smaller
> one,
> > > > depending
> > > > > on the content).
> > > > >
> > > > > As a general comment about size… in my experience over the last
> > 10
> > > years
> > > > or
> > > > > so, mostly in relation to Flex apps, size was most often not
> > among the
> > > > > highest priority issues. Sure, start-up time often was. But
> that
> > is not
> > > > > size per se. Often ‘size’ issues were first and foremost ‘asset
> > size’
> > > > > issues (embedded or separate). While I know overall that it
> > remains
> > > > > important, I personally think the growth in bandwidth and
> device
> > memory
> > > > in
> > > > > general has outpaced the growth in the size of web apps even as
> > the
> > > world
> > > > > has turned to mobile. In other words, I think we probably
> passed
> > a
> > > hurdle
> > > > > point in the mobile side of things. Admittedly that is just
> > > ‘perception’
> > > > > and maybe there is data that shows I am quite wrong or your
> > experience
> > > on
> > > > > specific client projects could be quite different. The point of
> > me
> > > > > explaining that was, however, to illustrate why I think ‘size’
> > sits
> > > > where I
> > > > > think it does in general in terms of importance: I consider it
> > to be
> > > > behind
> > > > > stability/reliability first which is followed by performance in
> > > > performance
> > > > > critical code. Overriding that general flow (which again, is
> > just my
> > > > > opinion), are whatever my client’s specific requirements are
> for
> > any
> > > > > particular project. In other words I am not sure how much of
> > > HelloWorld’s
> > > > > size is going to be an important deciding factor for someone to
> > choose
> > > to
> > > > > use Royale. I think the ‘I got it to work!’ is the real kicker
> > here.
> > > This
> > > > > paragraph was not to cause any conflict, and I already
> addressed
> > the
> > > > ‘size’
> > > > > impact in the branch, so I’m not saying it wasn’t necessary to
> > do that
> > > > > (although I do suspect the same attention was not given to all
> > other
> > > > things
> > > > > in the past that affected HelloWorld). It’s more to promote
> > discussion
> > > > and
> > > > > thought in general. Trying to be all one aspect (small size)
> can
> > > > compromise
> > > > > other aspects (reliability or stability or compatibility, for
> > example).
> > > > And
> > > > > trying to accommodate all aspects (reliability, small size,
> > exceptional
> > > > > performance) somehow very likely increases complexity because
> > there is
> > > a
> > > > > need to accommodate the explicit decisions for trade-offs
> between
> > > > competing
> > > > > aspects. It would be good to have a guide of priorities based
> on
> > the
> > > > needs
> > > > > of the user base (while I might have a strong opinion about
> what
> > I
> > > think
> > > > is
> > > > > important, I don’t assume that my views necessarily represent
> > wider
> > > user
> > > > > needs, because I have not done research to support that – and
> > it’s not
> > > > > really a twitter poll kind of thing!). Anyhow I got off track
> > there a
> > > > bit…
> > > > > back to Vector…
> > > > >
> > > > >
> > > > >
> > > > > *Performance.*
> > > > >
> > > > > No-one should expect a non-native Vector implementation to
> > perform
> > > faster
> > > > > than native Array in javascript. Its main benefit is type
> > safety, and
> > > > that
> > > > > is the reason it should be selected for use over Array. (In
> swf,
> > native
> > > > > numeric Vector types *are* selected for performance, but the
> > other
> > > Vector
> > > > > types are also at least slightly slower than Array, so
> selecting
> > them
> > > is
> > > > > based on the need for type safety)
> > > > >
> > > > > There are, however some ways to get 100% Array performance with
> > this
> > > > > implementation, and in a loop, for example it would be similar
> to
> > > > avoiding
> > > > > method calls (like push/pop) and only using index assignments
> > that is
> > > > > typical of performance optimization in swf.
> > > > >
> > > > > So these two methods provide almost Identical performance in
> js:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > *private function testArrayInt2(iterations:uint):Number{
> var
> > > > start:Date
> > > > > = new Date(); var inst:Array = new Array(iterations);
> > for
> > > > (var
> > > > > i:uint=0;i<iterations; i++) { inst[i] = i; }
> > return new
> > > > > Date().valueOf() - start.valueOf(); } /** * *
> > > > > @royalesuppressvectorindexcheck true */ private function
> > > > > testVectorInt2(iterations:uint):Number{ var start:Date =
> new
> > > Date();
> > > > > var inst:Vector.<uint> = new Vector.<uint>(iterations);
> > for
> > > > > (var i:uint=0;i<iterations; i++) { inst[i] = i; }
> > > return
> > > > > new Date().valueOf() - start.valueOf(); }*
> > > > >
> > > > > The doc comment on the 2nd method prevented the compiler from
> > > generating
> > > > an
> > > > > index check wrapper around the ‘i’ in inst[i]
> > > > >
> > > > > The above 2 methods take around 5-7 ms for 500,000 iterations
> on
> > my
> > > > machine
> > > > > (chrome/windows). This is quite a bit faster than the same
> > methods in
> > > the
> > > > > swf (non-debug) build on my machine. The Vector constructor is
> > also
> > > doing
> > > > > extra work in this case by setting all the 500,000 slots to
> > numeric 0.
> > > > But
> > > > > on modern browsers it is using a fast native Array.fill method
> > to do
> > > > that,
> > > > > so it’s probably more noticeable on IE11 which uses a for loop
> to
> > > > > pre-populate the contents with numeric 0 values.
> > > > >
> > > > > For reference, the generated code for the second method above,
> > looks
> > > like
> > > > > this:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > */** * * @royalesuppressvectorindexcheck true * @private *
> > @param
> > > > > {number} iterations * @return {number} */
> > > > >
> > > > >
> > > >
> > >
> >
> flexUnitTests.language.LanguageTesterTestVectorPerf.prototype.flexUnitTests_language_LanguageTesterTestVectorPerf_testVectorInt2
> > > > > = function(iterations) { var /** @type {Date} */ start = new
> > Date();
> > > > > var /** @type {Array.<number>} */ inst = new
> > > > >
> > (org.apache.royale.utils.Language.synthVector('uint'))(iterations);
> > > for
> > > > > (var /** @type {number} */ i = 0; i < iterations; i++) {
> > inst[i] =
> > > i;
> > > > > } return new Date().valueOf() - start.valueOf(); };*
> > > > >
> > > > > The methods with type checking in them, like push, unshift etc
> > will be
> > > > > quite a lot slower though. This should not be a surprise. In
> > swf, when
> > > > you
> > > > > look at something like Vector.<IBead> it can be up to 30%
> slower
> > than
> > > > Array
> > > > > for methods like push, iirc at native level. In javascript it
> > will be a
> > > > lot
> > > > > more. But in both cases it has type safety. And for small
> > collection
> > > > sizes
> > > > > in non-performance sensitive code it is probably not going to
> > make a
> > > > > meaningul difference.
> > > > >
> > > > > Known limitations
> > > > >
> > > > > 1. myVectorInstance[‘constructor’] can be different
> > between js
> > > and
> > > > > swf
> > > > >
> > > > > 2. There is some reliance on not obscuring the type from
> > the
> > > > compiler
> > > > > for things to work correctly. Example:
> > > > >
> > > > > var myObscuredType:* = new Vector.<String>(20,true) // creates
> a
> > fixed
> > > > > Vector of length 20
> > > > >
> > > > > myObscuredType.length = 21; //should throw an error, but does
> > not in
> > > > > javascript.
> > > > >
> > > > > This will work as long as the compiler knows that the type with
> > the
> > > > length
> > > > > setter is some type of Vector, otherwise not.
> > > > >
> > > > >
> > > > >
> > > > > *Performance tuning*
> > > > >
> > > > > *@royalesuppressvectorindexcheck*
> > > > >
> > > > > The above doc comment directive avoids checking for
> > out-of-valid-range
> > > > > index values on assignments. This is extremely desirable inside
> > loops
> > > > which
> > > > > are usually constrained to the valid range in any case. There
> is
> > a top
> > > > > level compiler configuration setting for this, but local
> > settings win
> > > > > (turning off or on generally with true/false, or suppressing
> > > specifically
> > > > > for individual local variable names)
> > > > >
> > > > >
> > > > >
> > > > > Other options.
> > > > >
> > > > > The above one was obvious to me as an important tuning option.
> I
> > > started
> > > > > with adding another but pulled it out in favor of adding them
> > based on
> > > > > actual need.
> > > > >
> > > > > There are many options:
> > > > >
> > > > > Instance based: reducing type checking with a compiler-only
> > generated
> > > > > additional constructor parameter, triggered by some doc comment
> > > > directive.
> > > > > This could be in the form of adding in compiler generated
> > alternatve
> > > > calls
> > > > > to things like ‘unsafePush’ and ‘unsafePop’ on instances, or
> > perhaps
> > > > > literal calls to Array.prototype.push.call(inst, pushItem),
> > triggered
> > > by
> > > > > some doc comment directive
> > > > >
> > > > > Global changes:Adding some compiler define value that (along
> > with:
> > > > > ||goog.DEBUG) suppresses many runtime checks in the release
> > Vector
> > > > > implementation. This would allow a blanket approach to dialing
> > runtime
> > > > > safety down (or keeping them) in the release build. It would
> > apply
> > > across
> > > > > all libraries and local project code.
> > > > >
> > > > > Some combinations of the above that allow sweeping
> optimizations
> > with
> > > > local
> > > > > exceptions.
> > > > >
> > > > > Basically, this branch currently represents what I have reason
> to
> > > believe
> > > > > is a high conformance Vector implementation which should be the
> > default
> > > > as
> > > > > it is an as3 core type. I think there are many options to scale
> > things
> > > > > back, but rather than assume what they should be, I’d prefer to
> > hear
> > > from
> > > > > users and address *real* needs, so that we only end up with
> > > configuration
> > > > > options that matter.
> > > > >
> > > > >
> > > > >
> > > > > *Advantages of a single Vector implementation – the case for
> > avoiding a
> > > > > ‘vector emulation class’*
> > > > >
> > > > > ‘Language emulation’ is a foundational layer that is not in the
> > same
> > > > > category as ‘application framework’ where we can define things
> > how we
> > > > want.
> > > > > Because the royale sdk includes both aspects inside ‘framework’
> > (and
> > > that
> > > > > was obviously not the case for flex sdk in the past) it may be
> > easy to
> > > > > overlook that difference.
> > > > >
> > > > > Vector typing is a core part of AS3 language. Therefore it
> should
> > > conform
> > > > > and be reliable. Having multiple implementations for a core
> > language
> > > > > feature seems wrong and could easily lead to libraries of code
> > that are
> > > > > incompatible. Additionally, as pointed out earlier, Vector is
> > more
> > > like a
> > > > > subclass factory (‘runtime’ generics) than a single class, so
> > won’t be
> > > > well
> > > > > represented by a regular class implementation.
> > > > >
> > > > > Alex, I know you added support for a Vector emulation class
> > approach to
> > > > > meet the needs of someone asking for improved Vector support,
> in
> > part
> > > > > because we did not have someone who had volunteered to write
> our
> > own. I
> > > > did
> > > > > that last part now. I am also suggesting that the emulation
> class
> > > > approach
> > > > > is not a good long term solution because of the above reasons.
> > And the
> > > > full
> > > > > set of functionality is less than 3Kb in the gzipped output, so
> > I’d
> > > > suggest
> > > > > that as long as I can add needs-based performance tuning
> options
> > for
> > > > those
> > > > > who want them, the benefits of having a single conforming
> > > implementation
> > > > > which is performance scalable are better than the risks
> > associated with
> > > > > adding partially non-conforming ones. Therefore I’d like to ask
> > if we
> > > can
> > > > > remove that functionality now that we have our own 'Vector' (I
> > can do
> > > the
> > > > > work if you prefer as I know your focus is understandably on
> > other
> > > > things).
> > > > >
> > > > > *Future:*
> > > > >
> > > > > It will be easily possibly to alter the current implementation
> > to use
> > > es6
> > > > > proxy which would likely provide the most reliable way to get
> > full
> > > Vector
> > > > > conformance indistinguishable from flash. Es6 proxy is
> > transparent for
> > > > > Array:
> > > > >
> > > > > var p = new Proxy(new Array(), {});
> > > > >
> > > > > Array.isArray(p) // true
> > > > >
> > > > > This should allow trapping things like the length setter before
> > it gets
> > > > to
> > > > > the underlying Array target, and doing checking for fixed ==
> > true etc.
> > > > The
> > > > > same is true for numeric index-based assignment of values etc.
> > > > >
> > > > > es6 Proxy is kinda cool. At the moment IE11 is the only
> > meaningful
> > > target
> > > > > that does not support this.
> > > > >
> > > > > I am only mentioning this here because I did think about this,
> > and I
> > > > > believe that the current implementation could be upgraded quite
> > easily
> > > to
> > > > > use this approach if it makes sense (when IE11 is a distant
> > memory –
> > > > > perhaps sometime next year!).
> > > > >
> > > > >
> > > > >
> > > > > Phew, you made it! Well done.
> > > > >
> > > > > Feel free to share your thoughts or ask any questions you might
> > have.
> > > If
> > > > > you have neither of those at this time, please still try to
> find
> > time
> > > to
> > > > > test any large projects you have in the branch, and provide
> > feedback or
> > > > > share any concerns you might have after doing that.
> > > > > thanks,
> > > > > Greg
> > > > >
> > > > >
> > > > > On Thu, May 23, 2019 at 7:55 PM Greg Dove <greg.dove@gmail.com
> >
> > wrote:
> > > > >
> > > > > > Re XMLTest manualtest...
> > > > > >
> > > > > > Yep those were the ones I ported, Harbs. I think I got them
> > all but
> > > may
> > > > > > have missed some. I added a bunch more as well. Hopefully
> > these can
> > > be
> > > > > > easily migrated to what Josh has been working on.
> > > > > >
> > > > > >
> > > > > > On Thu, 23 May 2019, 19:43 Harbs, <ha...@gmail.com>
> > wrote:
> > > > > >
> > > > > >> As far as XML unit tests go, the starting point should be
> > XMLTest in
> > > > > >> manual tests. (Almost) every time I ran into an issue, I
> > added it to
> > > > > that
> > > > > >> project.
> > > > > >>
> > > > > >> I think I might have been lax on the last few issues I
> fixed,
> > so we
> > > > > >> should probably go through the later XML commits and make
> > sure we
> > > have
> > > > > >> tests for that.
> > > > > >>
> > > > > >> As far as Node goes, I think we probably need conditional
> Node
> > > > > >> compilation to handle Node-specific (and browser specific)
> > code in a
> > > > > PAYG
> > > > > >> way.
> > > > > >>
> > > > > >> To technically handle the parsing, something like
> > > > > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=5Rl9DZfo3zo%2Bk1q3x%2FygT4HehZ3IAkC5VGRHbKZ8Fbo%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=5Rl9DZfo3zo%2Bk1q3x%2FygT4HehZ3IAkC5VGRHbKZ8Fbo%3D&reserved=0
> > >
> > > > is
> > > > > a
> > > > > >> good starting point and something like this
> > > > > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=TUTK%2BrNRsyS96dBdSDczi8qpEfTnhi4bgE5WmXORAnE%3D&reserved=0
> > <
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=TUTK%2BrNRsyS96dBdSDczi8qpEfTnhi4bgE5WmXORAnE%3D&reserved=0
> > >
> > > > > >> might be useful to either use or modify.
> > > > > >>
> > > > > >> Harbs
> > > > > >>
> > > > > >> > On May 23, 2019, at 10:18 AM, Greg Dove <
> > greg.dove@gmail.com>
> > > > wrote:
> > > > > >> >
> > > > > >> > All, I started porting some adhoc XML tests to UnitTests
> and
> > > > > eventually
> > > > > >> > ended up spending quite a bit of time on addressing issues
> > that
> > > > arose
> > > > > >> for
> > > > > >> > XML before getting back to Vector stuff.
> > > > > >> > I think XML probably needs many more unit tests before we
> > get to
> > > 1.0
> > > > > >> > because it has an extensive api. I have not used royale
> > with Node
> > > > yet,
> > > > > >> but
> > > > > >> > XML also needs some thought about how to get it working on
> > Node, I
> > > > > >> assume.
> > > > > >> > Because XML uses the browser's parser and Node does not
> > have one
> > > by
> > > > > >> > default, then using the same code will need something to
> > take the
> > > > > place
> > > > > >> of
> > > > > >> > the browser's native parser for Node. There is a lib in
> npm
> > that
> > > > might
> > > > > >> be
> > > > > >> > useful for that, but I don't know how that might work with
> > licence
> > > > > etc.
> > > > > >> > Anyhow, that is just an observation, I will focus on
> Vector
> > in
> > > this
> > > > > >> > thread... I will post here late tomorrow local time with
> > more
> > > info,
> > > > > and
> > > > > >> > discussion points. I am keen to see this merged in, but
> > also keen
> > > to
> > > > > get
> > > > > >> > buy-in first.
> > > > > >> >
> > > > > >> >
> > > > > >> > On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <
> > > > > carlosrovira@apache.org
> > > > > >> >
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> >> 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.dove@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.dove@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
> > > > <aharui@adobe.com.invalid
> > > > > >
> > > > > >> >>>> wrote:
> > > > > >> >>>>
> > > > > >> >>>>> +1 to renaming the options to the positive.
> > > > > >> >>>>>
> > > > > >> >>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <
> > joshtynjala@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.dove@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%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=FgEQxhJYmuPRHJCp%2BU252ksKsI86IzXXC42N1V98sK8%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%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=0YKmOa48l7mIYYmuA6bJ%2FGQYDEd%2BMutJvSQp9k0sGyI%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*
> >
Re: Language improvements
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
I think PAYG is very important to all of us. And I'm with you that PAYG is
itself more important than the fact that a small Kbs incrementation (as a
concept itself). We always have it in mind. But in this concrete case, I
think Vector is part of the AS3 base and Greg have a first implementation
for it. For me is like to have String, Number, Date...
So, nothing stops Greg, you or others to continue evolving it to improve
PAYG in this implementation, but that should happen IMHO after we have this
one, Since that will not happen any time soon. And better to have something
than nothing.
In the other hand, maybe in this concrete case discussion over Vector and
PAYG could derive in community be happy with current implementation or
wanting more options.
People will need time to work and experiment with this implementation and
could report they are happy or they find problems.
Or people can report they want other kind of implementation, in case that
will be a great point to make it more PAYG (although always that will
requiere the time, knowledge and effort to make it happen).
What I want to expose is that we should embrace this new implementation as
the step one, and progress from there to other status little by little
since sometimes trying to reach to the maximum goal we have in mind could
be very expensive in terms of time, effort and will left us with the
possibility to have today the feature, while if we do little by little, we
have both, the feature and the possibility to continue improving it to be
better (in this case the possibility to be more PAYG). Perfection is enemy
of progress.
ITOH, that will be great too since the natural process could make this
implementation will be chosen by community as something final...or
not....so for me, let's merge it, since is good and is a great step
forward, and then continue discussing it to see next steps. The later could
make this evolve more or not...what is clear is that will be weeks or
months ahead. That's what we've done with many other features in Royale,
some of them still in progress (Jewel, themes, compoenents,...)
People could want choices or not, but current branch will give all of us a
first choice since we have 0 right now. Then we can move to convert this on
multi-choice if community want it, and chances are that people is not
interested in that...or not...we should see.
El dom., 26 may. 2019 a las 1:10, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Hi Greg,
>
> Thanks for working through all of this. Better Vector handling is
> definitely a good thing for Royale.
>
> However, IMO, PAYG is more important and 3KB can be a full second or more
> on busy/slow/poor networks. As such, folks need to have choices. So as
> long as folks can choose Vector implementations we should be good.
>
> Flex failed in some major vendors' customer-facing apps because of
> download times. I have spent the past years trying to make sure Royale
> does not repeat those mistakes.
>
> I have some comments on finer details, but let's see if we can agree on
> this higher-level issue first. We simply should offer people choices.
>
> Thanks,
> -Alex
>
> On 5/25/19, 2:45 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Hi Carlos, thanks for your feedback. In terms of PAYG, I just have a
> sense
> that at the language level, the 'default' should be that it *works* as
> per
> design.
> If I take the example of Vector... then numeric Vector types will not
> run
> faster in javascript. Using all the method calls will have a
> substantial
> impact compared to using a normal Array. But code should 'work' the
> same
> across targets.
> I do have some ideas for application framework classes outside
> 'language'/Vector that would provide target-agnostic fast regular class
> implementations for numeric typed Arrays, and I hope to work on that
> soon
> as well, which takes more advantage of the optimized native options on
> each
> target (Vector in swf, TypedArray in javascript). But to achieve that
> it
> will likely be 'always fixed length' in this case, I will see if it
> seems
> worth trying to be able to toggle that, or maybe it can be a bead or
> opt-in
> support to get that functionality. But that should provide a good
> option
> for developers seeking to get the best performance for numeric
> collections.
> I expect to work on this during June.
> Or developers can of course always choose to implement their own custom
> performance code in COMPILE::JS / COMPILE::SWF variations, which is
> always
> an option.
>
>
> Hi Piotr, sorry about that email formatting issue. Thanks for your
> follow
> up on this.
> Here is a paste of that part, which includes the code.
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdPWy&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212062967&sdata=17ke54YZccaT%2BCQNKJLeihpTrSb2Nf4JB37o6c4ozGs%3D&reserved=0
>
> Also, if you want to see the tests for Vector, you can see them 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&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=GbM8oh6UkKpVE2HsdKwHgt6RgRJ9iNWIlCAhiubmHTk%3D&reserved=0
>
>
> You should see large parts of that series of tests fail outside the
> branch, and in some cases there were compiler errors too iirc (or
> maybe I
> am confusing some compiler fixes I did for other things, can't be sure
> now)
>
>
>
> On Sun, May 26, 2019 at 4:58 AM Carlos Rovira <carlosrovira@apache.org
> >
> wrote:
>
> > Hi!
> >
> > Read it! :), was long but I think this emails are needed since it
> brings
> > many thoughts that only the developer knows and otherwise would end
> never
> > known by the rest of the community. So Great!
> >
> > Greg, first, many thanks for working on this. I think we get other
> point
> > solved, and I think not only Vector, but many other fixes and things
> coming
> > in your branch.
> >
> > For my part, as you said, the branch is tested against my real
> project,
> > that I think is a very good way to test against lots of working
> code. So
> > for my is ok to merge, not only cause it does not brake anything,
> but cause
> > it's a big step forward.
> >
> > Since it brings things we didn't have before like Vector, is good to
> bring
> > this. Then we can continue iterating to add missed things like AMF
> support
> > or to evolve to other state or even change internal things if other
> check
> > and see ways of enhancements.
> >
> > About the Vector implementation. My opinion is that I think as you
> that
> > Vector is an intrinsic part of AS3, so better to have an
> implementation to
> > complete AS3 in Royale. About having multiple implementations, I
> think that
> > could be good in the future if things can be done that way, but
> better
> > start from this starting point and see what happens in next
> months-years.
> > IOW, better have a real implementation now that a potentially one
> that
> > still is not here. We need to see the goal and approach to it
> progressively
> > or we end getting nothing since the goal is a huge one not easy to
> reach.
> >
> > For me the 3kb is totally normal, and as well a great achievement of
> your
> > implementation.
> > I must say that my way of thinking in Royale is to be totally
> aligned with
> > concepts like PAYG, but sometimes we need to break rules when the
> goal
> > demand it, or we can end trying to apply the same principle to all
> things,
> > when sometimes is not the best. So this is importante, rules are
> really
> > good, but we need to always put behind a layer of human thinking
> about what
> > we are trying to accomplish
> >
> > Thanks Greg for reaching another important milestone! Amazing work!
> :)
> >
> > Carlos
> >
> > PD: Piotr, about gmail cutting the email, I'm using gmail and get to
> read
> > it completely, maybe could be a problem of gmail in mobile? I'm
> reading on
> > gmail desktop. The only problem I had was reading posted source
> code, but
> > since it was tiny, I could finally read it...
> >
> >
> >
> >
> >
> > El sáb., 25 may. 2019 a las 15:37, Piotr Zarzycki (<
> > piotrzarzycki21@gmail.com>) escribió:
> >
> > > Hi Greg,
> > >
> > > Could you please post the code from this email in the
> paste.apache.org -
> > > right now is unreadable in my Gmail account.
> > >
> > > Thanks,
> > > Piotr
> > >
> > > On Sat, May 25, 2019, 4:51 AM Greg Dove <gr...@gmail.com>
> wrote:
> > >
> > > > OK, At the risk of making what follows even longer... a warning:
> *this
> > > is a
> > > > long read*. It might veer off topic in one or two places, but it
> is
> > > mostly
> > > > about why, and how Vector is implemented the way it is in the
> branch.
> > > > Basically I would like to merge this branch into develop as soon
> as
> > > > possible, i actually think it is ready as is, but I am keen to
> get
> > other
> > > > input before I do.
> > > > Read it if you're interested. If you're not interested in
> reading it
> > then
> > > > please try the branch on any 'real' projects that you have in
> play.
> > > Carlos
> > > > has tested against his, and there are no issues, but it would be
> good
> > to
> > > > get wider input.
> > > >
> > > > now to the textual onslaught:
> > > >
> > > >
> > > > *Vector*
> > > >
> > > > One of the things I did before I worked on this Vector
> implementation
> > was
> > > > to detach myself from ‘how I use Vector when I code’, to take a
> step
> > back
> > > > and challenge myself to rethink how I thought about it in
> general.
> > > >
> > > > Vector is *special*. Vector is not *a class* in a typical sense.
> It is
> > > the
> > > > closest thing that as3 has to generics which, when used at a
> class
> > > level, I
> > > > like to think of as the ability to generate multiple class
> variations
> > > from
> > > > a single class definition (that is just the way I think of
> them). So,
> > at
> > > > some level Vector could be considered as an infinite set of
> distinct
> > > > classes, based on an infinite set of possible specified element
> types
> > > > (whatever you see between the angle brackets in code). It is not
> > actually
> > > > implemented natively in AVM this way iiuc, but that is the
> outward
> > > > appearance, and that is also the behaviour it has when using type
> > > checking
> > > > in as3.
> > > >
> > > > Aside from the runtime typesafe behaviour, Vector’s strong
> typing means
> > > > there is additional compile time support and, related, the
> possibility
> > of
> > > > extra IDE support, both of which help the developer.
> > > >
> > > > Vector ‘types’ are also final ‘classes’ enforced by the
> compiler, so
> > > cannot
> > > > be extended.
> > > >
> > > > Additionally, on looking closer, there are some other quirky
> rules for
> > > > runtime typing behaviour. These are related to the
> implementation in
> > AVM.
> > > > The 3 Vector types for Vector.<int>, Vector.<uint>, and
> Vector.<Number>
> > > are
> > > > individual base types, and then there is a 4th base type,
> Vector.<*>
> > > which
> > > > serves as the ‘base class’ of all other Vector ‘subclasses’. The
> 3
> > > numeric
> > > > types are faster than Array, and I expect this was the reason
> for the
> > > > separation, because these are used in a lot of other flash apis,
> > > > particularly for swapping with byte level data and things like
> > BitmapData
> > > > etc. The others are more simply for the strong typing aspects,
> because
> > > > (perhaps less so with Boolean and String at a guess) they are
> somewhat
> > > > slower than Array in AVM, because of the overhead of runtime
> > typechecking
> > > > and coercions etc. So the main selling points for choosing a
> Vector in
> > > > flash were a) compile time and runtime type safety and b) faster
> > > > performance for the 3 numeric Vector types.
> > > >
> > > > One implication of these ‘rules’ means that to check if
> *something* is
> > a
> > > > Vector of any type in swf, I need to do (mything is Vector.<int>
> ||
> > > myThing
> > > > is Vector.<uint> || myThing is Vector.<Number> || myThing is
> > Vector.<*>)
> > > or
> > > > use reflection (which is slower).
> > > >
> > > > The above implies that, for language conformance (considered as
> > > conformance
> > > > with as3 documentation/spec and the behaviour of the reference
> > > > implementation that we have for any ‘unknowns’) in an emulation,
> a
> > > regular
> > > > single as3 class implementation would not create a result that is
> > > > consistent with the spec in terms of its representation of
> typing, and
> > > its
> > > > behaviour when using type checking.
> > > >
> > > > I tried to take all of these things into consideration.
> > > >
> > > >
> > > >
> > > > *How is it implemented in the branch?*
> > > >
> > > > Vector is implemented using the lightweight ‘synthType’ approach
> I
> > added
> > > > previously to support for int and uint types as ‘classes’. This
> > provides
> > > a
> > > > light integration for ‘is’ and ‘as’ checks, but in javascript
> itself a
> > > > Vector instance is simply a tagged native javascript Array
> instance
> > (i.e.
> > > > an Array with something that identifies it as being ‘not a
> regular
> > > Array’).
> > > > The Array methods are enhanced at the instance level to support
> the
> > type
> > > > coercions that take place in an actionscript Vector. Using Array
> makes
> > > > sense because Vector instances are essentially typed Arrays. But
> it is
> > > not
> > > > possible to extend Array in javascript and have things work
> properly
> > (it
> > > is
> > > > possible to use a different approach with es6 Proxy, but that is
> not
> > > > available in IE11).
> > > >
> > > > This implementation also means that a ‘Vector’ instance should
> have
> > > > functionality that works mostly as expected if it is passed
> directly to
> > > a 3
> > > > rd party native javascript library that is expecting an Array
> instance.
> > > It
> > > > will not support errors when changing the length if the Vector
> instance
> > > is
> > > > ‘fixed’ length, for example but otherwise it should function
> much the
> > > same
> > > > as a regular Array in the 3rd party code.
> > > >
> > > > The ‘synthType’ approach can be used because Vector types are
> final, so
> > > it
> > > > does not need to conform to a regular Royale class definition
> that can
> > be
> > > > extended and can be much ‘lighter’. As with int and uint
> ‘classes’, no
> > > > Vector constructor exists until the first one is requested.
> There is
> > one
> > > > internal private class in Language that provides most of the
> > > functionality
> > > > for Vector, and element coercion functions are generated
> specifically
> > for
> > > > each Vector ‘subtype’. Overall, it behaves more like a subclass
> > ‘factory’
> > > > with each individual type’s constructor being created on demand
> and
> > > cached
> > > > for future use.
> > > >
> > > > Reflection and serialization support have not been added yet,
> but I
> > > > certainly had these in mind also with this approach. I just
> wanted to
> > > reach
> > > > a sensible intermediate point for now, and then add those in
> later.
> > > >
> > > > In summary, the Vector implementation in the branch provides the
> > > following:
> > > >
> > > > -distinct types (conforming in terms of type checking) for each
> Vector
> > > > subtype
> > > >
> > > > -lightweight integration with Language ‘is’ and ‘as’ support
> > > >
> > > > -each Vector subtype has a unique constructor generated the
> first time
> > it
> > > > is requested, the constructor does not exist prior to that.
> > > >
> > > > -expected to be compatible with 3rd party native javascript that
> > expects
> > > a
> > > > regular javascript Array
> > > >
> > > > -serialization (amf) and reflection are not yet supported but
> were
> > > > considered, and that is planned as next steps.
> > > >
> > > > As at the time of writing, the current implementation is
> supported by
> > 300
> > > > Vector-specific assertions that run side-by-side between
> javascript and
> > > swf
> > > > in the manualtest UnitTests project. Apart from the differences
> created
> > > by
> > > > explicitly switching off some type safety checks with
> > > > @suppressvectorindexchecking, there is only one verifiable
> difference
> > in
> > > > these tests between swf and javsacript. Probably there are things
> > outside
> > > > the test coverage that might need addressing still, but I think
> it’s a
> > > > pretty good start.
> > > >
> > > > These tests should be easily ported to framework level unit tests
> > > > (RoyaleUnit) as the same approach has been used to add FlexUnit
> tests
> > in
> > > > the past. Testing/Development is primarily in Chrome on windows,
> but
> > the
> > > > same tests were subsequently verified on IE11, Edge, Opera and
> Firefox
> > on
> > > > windows.
> > > >
> > > > *Implementation Info*
> > > >
> > > > *More quirks*
> > > >
> > > > A ‘fixed == true’ Vector cannot have its length changed. This
> means
> > that
> > > > changes via the length setter and the mutation methods (push,
> pop,
> > shift,
> > > > unshift etc) all throw errors if used when a Vector is ‘fixed ==
> true’.
> > > > But… splice method also can change length. And in AVM this works
> even
> > > with
> > > > a fixed length Vector, which might possibly be a bug but is one
> that is
> > > > matched in the implementation to conform with flash.
> > > >
> > > > *Size impact.*
> > > >
> > > > Alex was concerned with size impact for HelloWorld because the
> beads
> > were
> > > > using a Vector.<IBead> type in javascript in one of the
> application
> > > > framework base classes. But the requirement was for that to
> simply to
> > be
> > > an
> > > > Array in javascript, the compiler was only achieving that by
> default
> > > > because there was no real Vector implementation. So I did a
> couple of
> > > > things here. Firstly I changed the application framework code to
> > reflect
> > > > the different requirement for javascript. Secondly, I added some
> doc
> > > > comment directives to suppress exporting on public members. Then
> I
> > added
> > > > this to the Language methods that are for compiler-generated
> Vector
> > (and
> > > > int and uint) support so that they are eligible for dead code
> > elimination
> > > > if not used. This effectively means that it is fully PAYG – it
> is only
> > > > there if you need it, but if you need it there is also no effort
> to add
> > > it
> > > > in as an optional dependency. If, because of this, there is a
> potential
> > > for
> > > > issues with modules or something I have not thought of, that
> will be
> > > > another thing to solve, but if so, I will find a way to address
> it.
> > > >
> > > > If the main concern with ‘size’ is data transfer, then looking
> at the
> > > > minified output size in HelloWorld is not really meaningful (or
> perhaps
> > > it
> > > > is better to say that it is only as meaningful as looking at the
> size
> > of
> > > an
> > > > uncompressed swf compared to normal deployment of a compressed
> swf). In
> > > any
> > > > real deployment the javascript should be served as gzipped. So I
> > compared
> > > > gzipped (‘normal’ compression) versions of HelloWorld.js between
> those
> > > with
> > > > the unused Language support methods (for int/uint and Vector)
> and their
> > > > dependencies vs. builds without. The support for all that
> functionality
> > > > comes in at under 3 Kb difference in the gzipped output. I
> personally
> > > don’t
> > > > think that would register as important in most cases. However,
> it is
> > > pretty
> > > > close to zero impact now if it is not used. In fact the
> HelloWorld
> > > > application is now about 55 bytes smaller than it was before, so
> I
> > > consider
> > > > it ‘carbon-netural’. And these are at the gzipped levels (it is
> also
> > > > slightly smaller when not gzipped, although it can sometimes be
> the
> > case
> > > > that the larger of 2 files compresses better than a smaller one,
> > > depending
> > > > on the content).
> > > >
> > > > As a general comment about size… in my experience over the last
> 10
> > years
> > > or
> > > > so, mostly in relation to Flex apps, size was most often not
> among the
> > > > highest priority issues. Sure, start-up time often was. But that
> is not
> > > > size per se. Often ‘size’ issues were first and foremost ‘asset
> size’
> > > > issues (embedded or separate). While I know overall that it
> remains
> > > > important, I personally think the growth in bandwidth and device
> memory
> > > in
> > > > general has outpaced the growth in the size of web apps even as
> the
> > world
> > > > has turned to mobile. In other words, I think we probably passed
> a
> > hurdle
> > > > point in the mobile side of things. Admittedly that is just
> > ‘perception’
> > > > and maybe there is data that shows I am quite wrong or your
> experience
> > on
> > > > specific client projects could be quite different. The point of
> me
> > > > explaining that was, however, to illustrate why I think ‘size’
> sits
> > > where I
> > > > think it does in general in terms of importance: I consider it
> to be
> > > behind
> > > > stability/reliability first which is followed by performance in
> > > performance
> > > > critical code. Overriding that general flow (which again, is
> just my
> > > > opinion), are whatever my client’s specific requirements are for
> any
> > > > particular project. In other words I am not sure how much of
> > HelloWorld’s
> > > > size is going to be an important deciding factor for someone to
> choose
> > to
> > > > use Royale. I think the ‘I got it to work!’ is the real kicker
> here.
> > This
> > > > paragraph was not to cause any conflict, and I already addressed
> the
> > > ‘size’
> > > > impact in the branch, so I’m not saying it wasn’t necessary to
> do that
> > > > (although I do suspect the same attention was not given to all
> other
> > > things
> > > > in the past that affected HelloWorld). It’s more to promote
> discussion
> > > and
> > > > thought in general. Trying to be all one aspect (small size) can
> > > compromise
> > > > other aspects (reliability or stability or compatibility, for
> example).
> > > And
> > > > trying to accommodate all aspects (reliability, small size,
> exceptional
> > > > performance) somehow very likely increases complexity because
> there is
> > a
> > > > need to accommodate the explicit decisions for trade-offs between
> > > competing
> > > > aspects. It would be good to have a guide of priorities based on
> the
> > > needs
> > > > of the user base (while I might have a strong opinion about what
> I
> > think
> > > is
> > > > important, I don’t assume that my views necessarily represent
> wider
> > user
> > > > needs, because I have not done research to support that – and
> it’s not
> > > > really a twitter poll kind of thing!). Anyhow I got off track
> there a
> > > bit…
> > > > back to Vector…
> > > >
> > > >
> > > >
> > > > *Performance.*
> > > >
> > > > No-one should expect a non-native Vector implementation to
> perform
> > faster
> > > > than native Array in javascript. Its main benefit is type
> safety, and
> > > that
> > > > is the reason it should be selected for use over Array. (In swf,
> native
> > > > numeric Vector types *are* selected for performance, but the
> other
> > Vector
> > > > types are also at least slightly slower than Array, so selecting
> them
> > is
> > > > based on the need for type safety)
> > > >
> > > > There are, however some ways to get 100% Array performance with
> this
> > > > implementation, and in a loop, for example it would be similar to
> > > avoiding
> > > > method calls (like push/pop) and only using index assignments
> that is
> > > > typical of performance optimization in swf.
> > > >
> > > > So these two methods provide almost Identical performance in js:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > *private function testArrayInt2(iterations:uint):Number{ var
> > > start:Date
> > > > = new Date(); var inst:Array = new Array(iterations);
> for
> > > (var
> > > > i:uint=0;i<iterations; i++) { inst[i] = i; }
> return new
> > > > Date().valueOf() - start.valueOf(); } /** * *
> > > > @royalesuppressvectorindexcheck true */ private function
> > > > testVectorInt2(iterations:uint):Number{ var start:Date = new
> > Date();
> > > > var inst:Vector.<uint> = new Vector.<uint>(iterations);
> for
> > > > (var i:uint=0;i<iterations; i++) { inst[i] = i; }
> > return
> > > > new Date().valueOf() - start.valueOf(); }*
> > > >
> > > > The doc comment on the 2nd method prevented the compiler from
> > generating
> > > an
> > > > index check wrapper around the ‘i’ in inst[i]
> > > >
> > > > The above 2 methods take around 5-7 ms for 500,000 iterations on
> my
> > > machine
> > > > (chrome/windows). This is quite a bit faster than the same
> methods in
> > the
> > > > swf (non-debug) build on my machine. The Vector constructor is
> also
> > doing
> > > > extra work in this case by setting all the 500,000 slots to
> numeric 0.
> > > But
> > > > on modern browsers it is using a fast native Array.fill method
> to do
> > > that,
> > > > so it’s probably more noticeable on IE11 which uses a for loop to
> > > > pre-populate the contents with numeric 0 values.
> > > >
> > > > For reference, the generated code for the second method above,
> looks
> > like
> > > > this:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > */** * * @royalesuppressvectorindexcheck true * @private *
> @param
> > > > {number} iterations * @return {number} */
> > > >
> > > >
> > >
> >
> flexUnitTests.language.LanguageTesterTestVectorPerf.prototype.flexUnitTests_language_LanguageTesterTestVectorPerf_testVectorInt2
> > > > = function(iterations) { var /** @type {Date} */ start = new
> Date();
> > > > var /** @type {Array.<number>} */ inst = new
> > > >
> (org.apache.royale.utils.Language.synthVector('uint'))(iterations);
> > for
> > > > (var /** @type {number} */ i = 0; i < iterations; i++) {
> inst[i] =
> > i;
> > > > } return new Date().valueOf() - start.valueOf(); };*
> > > >
> > > > The methods with type checking in them, like push, unshift etc
> will be
> > > > quite a lot slower though. This should not be a surprise. In
> swf, when
> > > you
> > > > look at something like Vector.<IBead> it can be up to 30% slower
> than
> > > Array
> > > > for methods like push, iirc at native level. In javascript it
> will be a
> > > lot
> > > > more. But in both cases it has type safety. And for small
> collection
> > > sizes
> > > > in non-performance sensitive code it is probably not going to
> make a
> > > > meaningul difference.
> > > >
> > > > Known limitations
> > > >
> > > > 1. myVectorInstance[‘constructor’] can be different
> between js
> > and
> > > > swf
> > > >
> > > > 2. There is some reliance on not obscuring the type from
> the
> > > compiler
> > > > for things to work correctly. Example:
> > > >
> > > > var myObscuredType:* = new Vector.<String>(20,true) // creates a
> fixed
> > > > Vector of length 20
> > > >
> > > > myObscuredType.length = 21; //should throw an error, but does
> not in
> > > > javascript.
> > > >
> > > > This will work as long as the compiler knows that the type with
> the
> > > length
> > > > setter is some type of Vector, otherwise not.
> > > >
> > > >
> > > >
> > > > *Performance tuning*
> > > >
> > > > *@royalesuppressvectorindexcheck*
> > > >
> > > > The above doc comment directive avoids checking for
> out-of-valid-range
> > > > index values on assignments. This is extremely desirable inside
> loops
> > > which
> > > > are usually constrained to the valid range in any case. There is
> a top
> > > > level compiler configuration setting for this, but local
> settings win
> > > > (turning off or on generally with true/false, or suppressing
> > specifically
> > > > for individual local variable names)
> > > >
> > > >
> > > >
> > > > Other options.
> > > >
> > > > The above one was obvious to me as an important tuning option. I
> > started
> > > > with adding another but pulled it out in favor of adding them
> based on
> > > > actual need.
> > > >
> > > > There are many options:
> > > >
> > > > Instance based: reducing type checking with a compiler-only
> generated
> > > > additional constructor parameter, triggered by some doc comment
> > > directive.
> > > > This could be in the form of adding in compiler generated
> alternatve
> > > calls
> > > > to things like ‘unsafePush’ and ‘unsafePop’ on instances, or
> perhaps
> > > > literal calls to Array.prototype.push.call(inst, pushItem),
> triggered
> > by
> > > > some doc comment directive
> > > >
> > > > Global changes:Adding some compiler define value that (along
> with:
> > > > ||goog.DEBUG) suppresses many runtime checks in the release
> Vector
> > > > implementation. This would allow a blanket approach to dialing
> runtime
> > > > safety down (or keeping them) in the release build. It would
> apply
> > across
> > > > all libraries and local project code.
> > > >
> > > > Some combinations of the above that allow sweeping optimizations
> with
> > > local
> > > > exceptions.
> > > >
> > > > Basically, this branch currently represents what I have reason to
> > believe
> > > > is a high conformance Vector implementation which should be the
> default
> > > as
> > > > it is an as3 core type. I think there are many options to scale
> things
> > > > back, but rather than assume what they should be, I’d prefer to
> hear
> > from
> > > > users and address *real* needs, so that we only end up with
> > configuration
> > > > options that matter.
> > > >
> > > >
> > > >
> > > > *Advantages of a single Vector implementation – the case for
> avoiding a
> > > > ‘vector emulation class’*
> > > >
> > > > ‘Language emulation’ is a foundational layer that is not in the
> same
> > > > category as ‘application framework’ where we can define things
> how we
> > > want.
> > > > Because the royale sdk includes both aspects inside ‘framework’
> (and
> > that
> > > > was obviously not the case for flex sdk in the past) it may be
> easy to
> > > > overlook that difference.
> > > >
> > > > Vector typing is a core part of AS3 language. Therefore it should
> > conform
> > > > and be reliable. Having multiple implementations for a core
> language
> > > > feature seems wrong and could easily lead to libraries of code
> that are
> > > > incompatible. Additionally, as pointed out earlier, Vector is
> more
> > like a
> > > > subclass factory (‘runtime’ generics) than a single class, so
> won’t be
> > > well
> > > > represented by a regular class implementation.
> > > >
> > > > Alex, I know you added support for a Vector emulation class
> approach to
> > > > meet the needs of someone asking for improved Vector support, in
> part
> > > > because we did not have someone who had volunteered to write our
> own. I
> > > did
> > > > that last part now. I am also suggesting that the emulation class
> > > approach
> > > > is not a good long term solution because of the above reasons.
> And the
> > > full
> > > > set of functionality is less than 3Kb in the gzipped output, so
> I’d
> > > suggest
> > > > that as long as I can add needs-based performance tuning options
> for
> > > those
> > > > who want them, the benefits of having a single conforming
> > implementation
> > > > which is performance scalable are better than the risks
> associated with
> > > > adding partially non-conforming ones. Therefore I’d like to ask
> if we
> > can
> > > > remove that functionality now that we have our own 'Vector' (I
> can do
> > the
> > > > work if you prefer as I know your focus is understandably on
> other
> > > things).
> > > >
> > > > *Future:*
> > > >
> > > > It will be easily possibly to alter the current implementation
> to use
> > es6
> > > > proxy which would likely provide the most reliable way to get
> full
> > Vector
> > > > conformance indistinguishable from flash. Es6 proxy is
> transparent for
> > > > Array:
> > > >
> > > > var p = new Proxy(new Array(), {});
> > > >
> > > > Array.isArray(p) // true
> > > >
> > > > This should allow trapping things like the length setter before
> it gets
> > > to
> > > > the underlying Array target, and doing checking for fixed ==
> true etc.
> > > The
> > > > same is true for numeric index-based assignment of values etc.
> > > >
> > > > es6 Proxy is kinda cool. At the moment IE11 is the only
> meaningful
> > target
> > > > that does not support this.
> > > >
> > > > I am only mentioning this here because I did think about this,
> and I
> > > > believe that the current implementation could be upgraded quite
> easily
> > to
> > > > use this approach if it makes sense (when IE11 is a distant
> memory –
> > > > perhaps sometime next year!).
> > > >
> > > >
> > > >
> > > > Phew, you made it! Well done.
> > > >
> > > > Feel free to share your thoughts or ask any questions you might
> have.
> > If
> > > > you have neither of those at this time, please still try to find
> time
> > to
> > > > test any large projects you have in the branch, and provide
> feedback or
> > > > share any concerns you might have after doing that.
> > > > thanks,
> > > > Greg
> > > >
> > > >
> > > > On Thu, May 23, 2019 at 7:55 PM Greg Dove <gr...@gmail.com>
> wrote:
> > > >
> > > > > Re XMLTest manualtest...
> > > > >
> > > > > Yep those were the ones I ported, Harbs. I think I got them
> all but
> > may
> > > > > have missed some. I added a bunch more as well. Hopefully
> these can
> > be
> > > > > easily migrated to what Josh has been working on.
> > > > >
> > > > >
> > > > > On Thu, 23 May 2019, 19:43 Harbs, <ha...@gmail.com>
> wrote:
> > > > >
> > > > >> As far as XML unit tests go, the starting point should be
> XMLTest in
> > > > >> manual tests. (Almost) every time I ran into an issue, I
> added it to
> > > > that
> > > > >> project.
> > > > >>
> > > > >> I think I might have been lax on the last few issues I fixed,
> so we
> > > > >> should probably go through the later XML commits and make
> sure we
> > have
> > > > >> tests for that.
> > > > >>
> > > > >> As far as Node goes, I think we probably need conditional Node
> > > > >> compilation to handle Node-specific (and browser specific)
> code in a
> > > > PAYG
> > > > >> way.
> > > > >>
> > > > >> To technically handle the parsing, something like
> > > > >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=5Rl9DZfo3zo%2Bk1q3x%2FygT4HehZ3IAkC5VGRHbKZ8Fbo%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=5Rl9DZfo3zo%2Bk1q3x%2FygT4HehZ3IAkC5VGRHbKZ8Fbo%3D&reserved=0
> >
> > > is
> > > > a
> > > > >> good starting point and something like this
> > > > >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=TUTK%2BrNRsyS96dBdSDczi8qpEfTnhi4bgE5WmXORAnE%3D&reserved=0
> <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=TUTK%2BrNRsyS96dBdSDczi8qpEfTnhi4bgE5WmXORAnE%3D&reserved=0
> >
> > > > >> might be useful to either use or modify.
> > > > >>
> > > > >> Harbs
> > > > >>
> > > > >> > On May 23, 2019, at 10:18 AM, Greg Dove <
> greg.dove@gmail.com>
> > > wrote:
> > > > >> >
> > > > >> > All, I started porting some adhoc XML tests to UnitTests and
> > > > eventually
> > > > >> > ended up spending quite a bit of time on addressing issues
> that
> > > arose
> > > > >> for
> > > > >> > XML before getting back to Vector stuff.
> > > > >> > I think XML probably needs many more unit tests before we
> get to
> > 1.0
> > > > >> > because it has an extensive api. I have not used royale
> with Node
> > > yet,
> > > > >> but
> > > > >> > XML also needs some thought about how to get it working on
> Node, I
> > > > >> assume.
> > > > >> > Because XML uses the browser's parser and Node does not
> have one
> > by
> > > > >> > default, then using the same code will need something to
> take the
> > > > place
> > > > >> of
> > > > >> > the browser's native parser for Node. There is a lib in npm
> that
> > > might
> > > > >> be
> > > > >> > useful for that, but I don't know how that might work with
> licence
> > > > etc.
> > > > >> > Anyhow, that is just an observation, I will focus on Vector
> in
> > this
> > > > >> > thread... I will post here late tomorrow local time with
> more
> > info,
> > > > and
> > > > >> > discussion points. I am keen to see this merged in, but
> also keen
> > to
> > > > get
> > > > >> > buy-in first.
> > > > >> >
> > > > >> >
> > > > >> > On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <
> > > > carlosrovira@apache.org
> > > > >> >
> > > > >> > wrote:
> > > > >> >
> > > > >> >> 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.dove@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.dove@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
> > > <aharui@adobe.com.invalid
> > > > >
> > > > >> >>>> wrote:
> > > > >> >>>>
> > > > >> >>>>> +1 to renaming the options to the positive.
> > > > >> >>>>>
> > > > >> >>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <
> joshtynjala@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.dove@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%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=FgEQxhJYmuPRHJCp%2BU252ksKsI86IzXXC42N1V98sK8%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%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=0YKmOa48l7mIYYmuA6bJ%2FGQYDEd%2BMutJvSQp9k0sGyI%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%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=X8FK2azZSpsIHBZZCzfww4GAxxpOIeznBz7VOBr8WTg%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
> > > > >> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=E6W9Pr%2FN8qCsgSOcyOyT9gnk5rq5fEtKQJW4Qb6UuxQ%3D&reserved=0
> > > > >> >>
> > > > >>
> > > > >>
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=E6W9Pr%2FN8qCsgSOcyOyT9gnk5rq5fEtKQJW4Qb6UuxQ%3D&reserved=0
> >
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Language improvements
Posted by Harbs <ha...@gmail.com>.
I looked into this some time ago. Working from memory, non-typed arrays might have been even faster than TypedArrays. Why that would be, I can’t guess and I could be wrong about that.
I’d be interested in seeing some test results.
Thanks,
Harbs
> On May 28, 2019, at 10:39 AM, Greg Dove <gr...@gmail.com> wrote:
>
> For the TypedArray stuff it really only makes sense as a fixed Vector, not
> as one with fixed=false. I already made some suggestions about these to
> Harbs. Harbs thought the benefits might be dubious because of how
> optimizations work in V8 etc, but I would be surprised if there was not at
> least some small advantage, so I will check and if yes, I will work on that
> regardless.
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
Hi Alex,
I think there is probably a difference with patchy connections between
'using an app' (content) and 'installing an app' (download) whether its
mobile, desktop or web.
I suspect that most of the experience you describe is 'using an app'
whether it's git or anything else. And I do understand your frustration as
a user of anything in the scenario described.
I think it is particularly painful if you are doing something that is not
loading web app code from a local browser cache.
I accept that there is always a need for 'size' optimization in general and
there can be specific needs for sure.
What you can be sure of is that the problem with the network access is
going in one direction, and that is away from the 2KB size problem.
I see js apps in gzip sizes now that are not so dissimilar size to flex
apps from 10 years ago. The big difference of course is much more mobile
vs. desktop focus. As I said earlier in the thread, I believe the growth in
bandwidth will continue to outpace the growth in bytesize of web apps.
Perhaps not always their assets or other content, but in the apps
themselves.
Until the next big thing I guess... whatever that is.
But I'm obviously not getting my message through clearly on why I think it
is a bad idea to propagate different versions 'of the same thing'.
1. I am definitely in favor of options, including size based options for
those who need them. We are different in our thinking about priorities...
that's fine and doesn't matter as long as there are options for whoever
thinks whatever is more important.
2. I prefer options that do not have risks to Royale and its future
ecosystem. The possibility to 'break' language level classes and expose
them to others whose view of them remains unbroken is what drives my main
concern. The risk is unknowable at this point but it is also avoidable. I'm
guessing you either don't consider there are risks or you don't think they
are important (relative to other things that you consider more important).
Perhaps you think the risk is avoidable in ways I don't understand. If so,
I am curious to know what they are. But right now I can't think of them,
so...
FWIW I think about XML in exactly the same way as Vector here. It's
language, not application framework.
They are both part of the language layer.
As others have said, Vector and XML are like Date, Number etc. The fact
that that they are 'emulated' in local code should be something to be aware
of, but language is language. It either works as defined or it does not.
In the past we downloaded 'language support' in flash player via its
frequent updates. For Royale we need to download the selective non-native
language pieces we use that deliver that same compatible support along with
app itself.
As a hypothetical, if javascript did not have a Date implementation and
Royale had to (somehow) emulate that as well, I am curious to understand if
you think it would be sensible to encourage multiple non-conforming
implementations of Date (for whatever reason - better size/performance for
example), given that it also is well specified. Perhaps you do think its
ok, but I would not, and of course Date is not really a problem in
javascript. But that's the same way I think of Vector, and I'm only using
it to illustrate that. If we permit non-conforming implementations, we
should warn people who make libraries not to do certain things (always keep
references of this non-conforming type as 'private' or only use for local
vars etc) otherwise they may expose language level features that will not
be reliable elsewhere, because the alternate 'emulation' of that language
class is baked into the library and can be different to the one used in
other libraries or in the main app.
I'm talking about public swc libraries, not private ones, but even in large
teams it could be important to consider. Providing warnings about these
risks itself seems cumbersome and also has negative connotations.
"My understanding from the words you've written is that you want everyone
to use your Vector implementation and have options on what code paths that
implementation actually takes, but I don't understand why from a technical
perspective."
I don't think of this as 'my' Vector implementation. I do however want
people to be able to use 'our' Vector implementation with confidence, which
is why I posted so much information in this thread and asked others to try
it. Outputting as Array is *not* an implementation of Vector... imo it is a
placeholder waiting for one. Because there is nothing to distinguish it
from a regular Array, at a very basic level it is a misrepresentation of
strong typing.
I'm not sure what you mean by 'technical perspective' here. There could be
some technical issues if there was a need to be able to resolve two or more
conflicting runtime representations of the same type (emulation class 1 in
public library 1, emulation class 2 in public library 2 and default Vector
implementaion in the main app, all with instances made available to the
main app, for example), and I do actually wonder about runtime weight of
code that might be required to do that if it was needed, but I am sure any
technical issues could be overcome. My main concern is not technical. My
main concern is to do with quality and reputation and reliability and
dependability as it relates to how others perceive Royale if things like
this arose.
I imagine a new developer taking over from someone else in a large project
team would have to be warned to be careful with something because it does
not behave as the language reference says it should in all cases... even
though the compiler and the IDE that he or she is using both 'think' it
should. Or if they are *not* warned or otherwise informed, for them to be
thinking expletive-ridden thoughts about the project or about Royale when
things start to get strange for them. I imagine my colleagues on client
React projects who might try Royale at my suggestion encountering something
like this and I wince at the type of feedback I would get because the
published apis for the libraries they use 'sometimes only partially work'
and other times fully work when they expose emulation instances or Arrays
masquerading as Vectors.
Apart from people having bad experiences like that, there is also the
possibility of some people writing code that works 'correctly' because of a
dependence on something else that doesn't work right (because it is
non-conforming) and that code may then subsequently 'not work' if there
was later a change to the emulation class in the dependency and it became
'more conformant'. It's not the same things, but I experienced something
sort of like this with the AMF code that you originally ported which had
errors in the original js source (to be clear:not in your port of the
original, but in the original itself, so the errors were ported as-is),
errors that I can only assume were reinforced in a closed loop by the
companion serverside library that the original js lib was paired with -
fixing one and making it correct would break compatibility with the other
in that case.
If there is the possibility to have multiple representations of the same
Vector type via different 'emulations' then I think these risks are real. I
don't know how big the risk is. But unless I am missing something, I am
pretty sure the risk is not zero. And I know it is possible to make it
zero.
My earlier comments about 'code paths' (if I have interpreted that
correctly) was more about trying to address options for tuning the
performance of the implementation in the branch.
I have thought through some options for these, but again I am hesitant to
do things that add complexity/config options which might never be used, so
I would prefer to do it based on need.
And I would like to add more alternative options before we settle on the
'needs' for Vector tuning because maybe the needs are better served with
alternatives.( note: I mean other classes, not Vector emulation class
alternatives)
I'll make some quick comments about some of those in the other points you
mentioned. Then it's time to stop.... why? because: too much text.
"-Vector and XML and any other built-in for SWF that isn't in JS are not
free. We have to write some amount of code to get them to work. "
Yes that is normal. I like to think of it as little bits of the flash
player that are relevant to the app they are blended with in javascript.
Other languages/frameworks do exactly the same thing for the language level
stuff.
"-Vector provides runtime type checking. Not everybody needs runtime type
checking in production."
Agreed, but runtime checking is what it does by default and some people
*will* want it in production.
For implicit coercions of non-primitive types on assignment there is
already a way to switch that off in the branch. That has local build scope
or local method scope via doc comment directive. Note, this feature is not
Vector specific. It is off by default in the framework. This would mean
that when switched off you can do myThingVec[0] =
SomethingThatIsNotAMyThing and it would end up in your Vector instance even
though it should not. But you can eliminate those cases with it switched on
and then switch it off later.
For methods like push and unshift etc there is nothing to dial that back
yet, but I could easily add support to bypass the runtime checking and
directly call the native Array methods, without any extra byte-weight by
simply switching those calls to use Array.prototype.push.call(inst, args).
It looks long, but that will compress *extremely* well via gzip based on
most of it being repeated and on how gzip favors repeated string sequences.
This could also be via call site (containing method) or build level
settings. I think it is risky to make this instance based, because the
instance could be exposed to external code that requires it to work with
type safety in places it is used elsewhere. The presumption is that any
library that used the 'unsafe' optimizations made sure they were 'safe' but
external code should not have that assumption by default.
"-Vector provides length checking. Not everybody needs length checking in
production. "
This is switchable off already for the index level assignments. It was an
obvious one. It can be switched off for all Vectors in the build, although
explicit local settings to force it on win if someone wants it on only for
specific cases with a build setting off.
If you want to avoid length checking in the runtime with the length setter,
that is also possible to avoid that now with dynamic access, but I have not
explained that anywhere.
basically myVec['length'] = 10 should do that now.
Setting length explicitly is usually relatively rare compared to doing
stuff with the contents. But if it was deemed necessary to add a setting
for that to avoid using the above approach, I could do that. I just don't
want to add un-needed configuration options for the sake of it.
"-We've already proven that by having at least two projects get into
production without your implementation of Vector.
-The current compiler output for Vector for folks who don't need runtime
checking just uses Array."
It sounds like Harbs might have used it a lot, but Carlos' app does not use
Vectors - only Array and ArrayList.
I can't consider the private beads IBead thing is a definitive validation
of Array-as-Vector in Carlos' production build.
For the TypedArray stuff it really only makes sense as a fixed Vector, not
as one with fixed=false. I already made some suggestions about these to
Harbs. Harbs thought the benefits might be dubious because of how
optimizations work in V8 etc, but I would be surprised if there was not at
least some small advantage, so I will check and if yes, I will work on that
regardless. I did consider these already in the early stages of the branch
implementation and it does not lend itself as a dropin replacement for
Vector with the Vector api, which permits toggling of fixed, unless you had
wrapper class that can toggle between Array and TypedArray - overall it
would be heavier than the implementation in the branch.
In terms of size, I probably still will be able to shave a few bytes off,
but returns for gzip can be marginal relative to effort when you get close
and sometimes you get more gzipped bytes for smaller minified code -
because of how gzip compression works best with repeated text (although GCC
does know this stuff and tries to do the right thing I think).
Hopefully I have outlined what I think are potential risks with
Vector-as-Array or emulation alternatives. You either agree with what I
explained or you don't. If you have a reason why it will never be a problem
because I was thinking about it wrong, then great, I'll be happy to hear
that.
If the consensus from the team is that there needs to be an Array output
option Vector, then let me know.
React has a performance option name I really like for something that makes
me think of things like this: dangerouslySetInnerHTML.
I'd certainly prefer the other options Harbs mentioned with compiletime
only typed Arrays - which is what Haxe also does (it limits some of the api
though, you can only push one element at a time for example without
breaking out into target level code switches).
But if majority still wants a Vector as Array option after (possibly)
reading everything I wrote then I will add it. You can just reply to this
thread or if someone wants to create a voting thread for that, I'm good
with the results. But I will never endorse using it myself. If I want Array
in javascript, I will make my code honest and make it an Array (or use some
new typed array option which gives me the compiletime only support!).
Slightly OT, but the only major thing left is a good Dictionary
implementation. That has one insurmountable challenge... because although
we can use weak keys now, it is impossible to enumerate over weak keys in
javascript. But apart from that (which is really something I will miss
compared to swf) it should be able to get pretty close i think.
I will wait a couple more days to hear back about the Array thing, or in
case people get the chance to try this branch and provide specific
feedback. Otherwise I will merge it, because I consider it ready to do so.
If the Array decision comes in after that, I will do it in develop.
On Tue, May 28, 2019 at 6:43 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> Hi Greg,
>
> I live outside of Seattle. I'm in my house right now, and my cellphone
> says I have a 4G connection. Many times a month, I take a ferry boat to
> Seattle. There is a point during the ride where the connectivity is poor.
> Yesterday, I was trying to get work done on the ferry and was blocked from
> doing one step in the release automation because it would not load in
> time. Many times, I'm trying to get one thing finished and get stymied by
> poor connectivity. I hear this complaint from plenty of other residents
> where I live. I want Royale to produce the app that loads when other apps
> don't. Forcing everyone to take on another 2000+ bytes is not going to
> help.
>
> The argument of "it is only another 1K" is what eventually caused
> UIComponent to grow to 13,000 lines and 128K Hello World. That's history.
> I do not want to repeat it.
>
> I still haven't had time to look at your changes or read and respond to
> all of the words you've written. Mostly for others who haven't been
> following the discussion, my reasoning is as follows:
>
> -Vector and XML and any other built-in for SWF that isn't in JS are not
> free. We have to write some amount of code to get them to work.
> -Vector provides runtime type checking. Not everybody needs runtime type
> checking in production.
> -Vector provides length checking. Not everybody needs length checking in
> production.
> -We've already proven that by having at least two projects get into
> production without your implementation of Vector.
> -The current compiler output for Vector for folks who don't need runtime
> checking just uses Array.
> -Your implementation adds 2990 bytes.
>
> For sure, we need an implementation that does runtime type-checking and
> length checking. So, as long as folks can choose to save the 2990 bytes
> and just use the current compiler output for Array in production, then we
> have given folks the right choices. Bonus if we can let folks choose other
> Vector implementations just like they can choose other XML
> implementations. My understanding from the words you've written is that
> you want everyone to use your Vector implementation and have options on
> what code paths that implementation actually takes, but I don't understand
> why from a technical perspective.
>
> In fact, I was reading up on Javascript TypedArrays (because that did load
> while on the ferry) and it looks like some folks might want Vector.<int> to
> map to the appropriate TypedArray. It actually got me wondering if folks
> should be able to dictate how any particular instance of a Vector
> "optimizes".
>
> In sum, the download size still matters. I see it quite frequently.
> Technically, why shouldn't folks have a choice of implementations?
>
> -Alex
>
> On 5/27/19, 2:46 AM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Hi Alex, sorry it can take a while for me to reply at the moment...
> some
> comments inline below...
>
> On Sun, May 26, 2019 at 11:10 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Hi Greg,
> >
> > Thanks for working through all of this. Better Vector handling is
> > definitely a good thing for Royale.
> >
>
> I also believe so. In terms of my motivation for doing this work... I
> actually have no imminent need for Vector, but I wanted to do something
> concrete which I think is essential for 1.0.
> I do have my own libraries and past client work from that use Vector,
> so I
> see benefit in knowing that it will be easy to port to Royale and work
> without any issues if I need to do that at any point (hopefully I
> will). I
> also got to see how Vector was treated differently/specially when
> working
> on AMF, and realized that we had no way to support it there correctly
> because it is 'special' also in amf, so that was another motivation
> (again,
> not for anything I actually need at the moment for myself or anyone
> else,
> but because it is something else that is lacking for 1.0).
>
> However, IMO, PAYG is more important and 3KB can be a full second or
> more
> > on busy/slow/poor networks. As such, folks need to have choices.
> So as
> > long as folks can choose Vector implementations we should be good.
> >
> > A couple of things here. Firstly, I really did not think I would
> need to
> be this specific... but iirc it was actually 2990 bytes.
> My first reaction to your scenario above would be: that network
> connection
> speed is really *unusable* for anything on today's internet... and
> that is
> a problem that should be addressed first, otherwise it does not matter
> which development tech you plan to use, it will be a common problem,
> royale, react... whatever.
> I can't recall something from my last 10 years where 3KB would be
> considered a driving force for an intervention that would (presumably)
> only
> save a portion of that (and introduce future potential maintainability
> risks). 3KB was less than a second on dialup over 20 years ago. Things
> have
> changed dramatically in the last 5 years in particular. We are in a HD
> streaming world now, with many countries supporting 4K streaming
> connection
> speeds. And average speeds continue to grow globally at solid rates
> year-on-year. 4G has impressive global coverage, and 5G is on the
> horizon.
> I did mention this generally my earlier comments about bandwidth growth
> outpacing growth in the size of apps. With your example are you
> hypothesizing or do you have a real recent example in mind where this
> type
> of thing was happening? If I was asked to classify the likelihood of
> the
> scenario you described I would describe it as a few standard deviations
> away from the center of the bell curve based on my own experience.
>
> However I absolutely do agree with you that choice is important, I just
> believe that performance most often will be more of a reason for the
> decision to choose alternates (and it may mean adding 'size', not
> reducing
> it).
> And I think the choice should be explicit/obvious rather than having
> something that is a lesser implementation of what it is actually
> supposed
> to be. By this, I mean more application framework alternatives,
> instead of
> supporting variations that represent non-conforming language classes.
> If
> that approach is used, I think it will result in clearer, better
> quality,
> more maintainable code. This is also a general approachI have observed
> elsewhere.
>
> Choosing Array is always an option in javascript and provides a zero
> byte-weight option. I also plan to introduce some options for the
> numeric
> types that represent best performance across both targets... but not as
> 'Vector' numeric types. The aim here would be to get faster than
> 'Vector as
> Array' in javascript and it will be just a convenience approach to
> avoid
> writing your own COMPILE::JS blocks with the native TypedArrays.
>
> In terms of tweaking this Vector implementation's performance as
> further
> options, I already explained I am happy to work on that based on actual
> feedback for need. But I still think it requires caution and
> consideration
> in terms of potential risks for people releasing libraries that could
> expose non-conforming instances of Vectors (something that can never
> happen
> in swf).
> There are perhaps some possibilities for enhancing [ArrayElementType]
> with
> a compiletime=true argument to get something more like what Harbs is
> after,
> but that would only work for class members, not local vars. Perhaps
> there
> are other simple ways to add 'compiletime' safety without going to full
> blown generics support yet.
>
>
> > Flex failed in some major vendors' customer-facing apps because of
> > download times. I have spent the past years trying to make sure
> Royale
> > does not repeat those mistakes.
> >
> >
> I do want you to understand that I'm on the same team. And like you, I
> don't want to repeat old mistakes too. But I also would like to see us
> avoid possible new ones.
> In the last 5 years or so, I have never really had a client spend much
> time
> focusing on the size. Before that I think I was more aware of it.
> Anyhow,
> it's not that it was never important at all, it's just that it was
> relatively unimportant compared to other aspects. And apart from
> remembering the size of flex apps in the past, I've seen the size of
> react
> apps I worked on recently too.
> I actually just looked at one of those. It is 8762KB minified and
> compresses to 1293KB gzipped. The app does not compare directly, but
> it is
> similar to Carlos' app in that it has many complex input rules and
> sequences, however in a lot of ways Carlos' app is far more complex
> and has
> a lot more remote API calls. However the final result from royale with
> Carlos's app has a much, much lighter footprint than those numbers for
> react. So Alex, I think the work you and others have put into avoiding
> unneeded weight in the application framework has paid (and will
> continue to
> pay) 'dividends' (as a metaphoric expression for anyone unfamiliar with
> that).
> But I do think of the language layer below the application framework
> layer
> as 'different' and that it should be treated as if it has existing
> specifications that are not free to reshape as we see fit (which it
> does,
> directly or indirectly). The language is still actionscript, it's not
> royalescript or jactionscript or something else. I've also spelt out a
> number of the reasons why I have these views earlier. One thing I did
> not
> mention was that my views also reflect my experience and observations
> with
> another cross platform language. I have seen some cases, for example,
> where
> over the course of iterative improvements, the use of native classes
> (the
> example that springs to mind was for XML parsing) was removed from a
> language level library and the whole feature was re-implemented in
> local
> code because it was more desirable to achieve consistency across
> targets
> than to have the best performing code on any one target. The IDE
> plugin for
> that particular sdk has over 120K downloads in the one IDE I use most
> often
> and it has a number of other IDEs supporting it with their own plugins
> etc.
> So I have reason to believe it is popular, and I know it is
> disciplined at
> the language level for a number of these shared target aspects. The
> consistency therefore seems to be very important to its user base,
> more so
> than the prospect of each language level feature 'being the smallest
> it can
> be'. But beyond the core language it also has lots of scope for
> accommodating differences. My exposure to this (and involvment with it
> in
> the past) has also influenced my thinking. I try to avoid thinking
> "that's
> them and not us" because that is a poor reason to ignore the learnings
> of
> others. Much of my own knowledge and skills over the years is the
> result of
> shared knowledge (royale and yourself included as a boost to that for
> which
> I am grateful). Anyway, part of the thinking does come from awareness
> of
> other things elsewhere, but I did pass it through my 'how does it
> relate to
> royale' filter.
>
>
> I have some comments on finer details, but let's see if we can agree on
> > this higher-level issue first. We simply should offer people
> choices.
> >
> > Just repeating: I too am keen to offer choices and also to make it
> easy to
> choose them. We only have different views over what those choices
> should
> be. I would prefer them to be safer choices. I believe avoiding the
> multiple Vector implementation approach will avoid future pitfalls and
> possible developer confusion that could arise from the distribution of
> inconsistent or non-conforming language level code. Neither of us can
> be
> certain if those risks are real. But there is one way to avoid them for
> sure (and yet still provide choices). That is essentially the crux of
> my
> thinking. Do you think that logic is reasonable at the higher-level?
>
> Beyond that, I did not obviously remove any emulationClass code in the
> compiler and would not do so without your agreement, so nothing there
> has
> changed.
> Actually in the branch I think I changed something to pass qualified
> name
> instead of basename somewhere, because base name would not be correct
> in
> the general case. For that reason I don't think anybody was using that
> feature yet, although I know you added it in response to a request from
> Joshua Granick, as a way to address the Array-not-Vector issue. I do
> not
> think it should be there now that we have something that we can call
> our
> own, which is why I asked if we could remove it. Anyway, in terms of
> that
> decision, can we agree to table it for now, merge the branch and maybe
> continue this discussion later? I will go ahead and work on the other
> 'choices' I have in mind regardless, maybe when you see them you might
> change how you think about things (or not, it is the apache way).
>
>
> > Thanks,
> > -Alex
> >
> > On 5/25/19, 2:45 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >
> > Hi Carlos, thanks for your feedback. In terms of PAYG, I just
> have a
> > sense
> > that at the language level, the 'default' should be that it
> *works* as
> > per
> > design.
> > If I take the example of Vector... then numeric Vector types
> will not
> > run
> > faster in javascript. Using all the method calls will have a
> > substantial
> > impact compared to using a normal Array. But code should 'work'
> the
> > same
> > across targets.
> > I do have some ideas for application framework classes outside
> > 'language'/Vector that would provide target-agnostic fast
> regular class
> > implementations for numeric typed Arrays, and I hope to work on
> that
> > soon
> > as well, which takes more advantage of the optimized native
> options on
> > each
> > target (Vector in swf, TypedArray in javascript). But to achieve
> that
> > it
> > will likely be 'always fixed length' in this case, I will see if
> it
> > seems
> > worth trying to be able to toggle that, or maybe it can be a
> bead or
> > opt-in
> > support to get that functionality. But that should provide a good
> > option
> > for developers seeking to get the best performance for numeric
> > collections.
> > I expect to work on this during June.
> > Or developers can of course always choose to implement their own
> custom
> > performance code in COMPILE::JS / COMPILE::SWF variations, which
> is
> > always
> > an option.
> >
> >
> > Hi Piotr, sorry about that email formatting issue. Thanks for
> your
> > follow
> > up on this.
> > Here is a paste of that part, which includes the code.
> >
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdPWy&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=2InnN50ng8lXwYsDKMZXNiEoHCcMDutiw%2BmOAifDqdc%3D&reserved=0
> >
> > Also, if you want to see the tests for Vector, you can see them
> 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&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sp48jNSTgvHikdp9A2d2L%2Bwkq5vcHII%2BBqD%2BiXczSaQ%3D&reserved=0
> >
> >
> > You should see large parts of that series of tests fail outside
> the
> > branch, and in some cases there were compiler errors too iirc (or
> > maybe I
> > am confusing some compiler fixes I did for other things, can't
> be sure
> > now)
> >
> >
> >
> > On Sun, May 26, 2019 at 4:58 AM Carlos Rovira <
> carlosrovira@apache.org
> > >
> > wrote:
> >
> > > Hi!
> > >
> > > Read it! :), was long but I think this emails are needed since
> it
> > brings
> > > many thoughts that only the developer knows and otherwise
> would end
> > never
> > > known by the rest of the community. So Great!
> > >
> > > Greg, first, many thanks for working on this. I think we get
> other
> > point
> > > solved, and I think not only Vector, but many other fixes and
> things
> > coming
> > > in your branch.
> > >
> > > For my part, as you said, the branch is tested against my real
> > project,
> > > that I think is a very good way to test against lots of working
> > code. So
> > > for my is ok to merge, not only cause it does not brake
> anything,
> > but cause
> > > it's a big step forward.
> > >
> > > Since it brings things we didn't have before like Vector, is
> good to
> > bring
> > > this. Then we can continue iterating to add missed things like
> AMF
> > support
> > > or to evolve to other state or even change internal things if
> other
> > check
> > > and see ways of enhancements.
> > >
> > > About the Vector implementation. My opinion is that I think as
> you
> > that
> > > Vector is an intrinsic part of AS3, so better to have an
> > implementation to
> > > complete AS3 in Royale. About having multiple implementations,
> I
> > think that
> > > could be good in the future if things can be done that way, but
> > better
> > > start from this starting point and see what happens in next
> > months-years.
> > > IOW, better have a real implementation now that a potentially
> one
> > that
> > > still is not here. We need to see the goal and approach to it
> > progressively
> > > or we end getting nothing since the goal is a huge one not
> easy to
> > reach.
> > >
> > > For me the 3kb is totally normal, and as well a great
> achievement of
> > your
> > > implementation.
> > > I must say that my way of thinking in Royale is to be totally
> > aligned with
> > > concepts like PAYG, but sometimes we need to break rules when
> the
> > goal
> > > demand it, or we can end trying to apply the same principle to
> all
> > things,
> > > when sometimes is not the best. So this is importante, rules
> are
> > really
> > > good, but we need to always put behind a layer of human
> thinking
> > about what
> > > we are trying to accomplish
> > >
> > > Thanks Greg for reaching another important milestone! Amazing
> work!
> > :)
> > >
> > > Carlos
> > >
> > > PD: Piotr, about gmail cutting the email, I'm using gmail and
> get to
> > read
> > > it completely, maybe could be a problem of gmail in mobile? I'm
> > reading on
> > > gmail desktop. The only problem I had was reading posted source
> > code, but
> > > since it was tiny, I could finally read it...
> > >
> > >
> > >
> > >
> > >
> > > El sáb., 25 may. 2019 a las 15:37, Piotr Zarzycki (<
> > > piotrzarzycki21@gmail.com>) escribió:
> > >
> > > > Hi Greg,
> > > >
> > > > Could you please post the code from this email in the
> > paste.apache.org -
> > > > right now is unreadable in my Gmail account.
> > > >
> > > > Thanks,
> > > > Piotr
> > > >
> > > > On Sat, May 25, 2019, 4:51 AM Greg Dove <greg.dove@gmail.com
> >
> > wrote:
> > > >
> > > > > OK, At the risk of making what follows even longer... a
> warning:
> > *this
> > > > is a
> > > > > long read*. It might veer off topic in one or two places,
> but it
> > is
> > > > mostly
> > > > > about why, and how Vector is implemented the way it is in
> the
> > branch.
> > > > > Basically I would like to merge this branch into develop
> as soon
> > as
> > > > > possible, i actually think it is ready as is, but I am
> keen to
> > get
> > > other
> > > > > input before I do.
> > > > > Read it if you're interested. If you're not interested in
> > reading it
> > > then
> > > > > please try the branch on any 'real' projects that you have
> in
> > play.
> > > > Carlos
> > > > > has tested against his, and there are no issues, but it
> would be
> > good
> > > to
> > > > > get wider input.
> > > > >
> > > > > now to the textual onslaught:
> > > > >
> > > > >
> > > > > *Vector*
> > > > >
> > > > > One of the things I did before I worked on this Vector
> > implementation
> > > was
> > > > > to detach myself from ‘how I use Vector when I code’, to
> take a
> > step
> > > back
> > > > > and challenge myself to rethink how I thought about it in
> > general.
> > > > >
> > > > > Vector is *special*. Vector is not *a class* in a typical
> sense.
> > It is
> > > > the
> > > > > closest thing that as3 has to generics which, when used at
> a
> > class
> > > > level, I
> > > > > like to think of as the ability to generate multiple class
> > variations
> > > > from
> > > > > a single class definition (that is just the way I think of
> > them). So,
> > > at
> > > > > some level Vector could be considered as an infinite set of
> > distinct
> > > > > classes, based on an infinite set of possible specified
> element
> > types
> > > > > (whatever you see between the angle brackets in code). It
> is not
> > > actually
> > > > > implemented natively in AVM this way iiuc, but that is the
> > outward
> > > > > appearance, and that is also the behaviour it has when
> using type
> > > > checking
> > > > > in as3.
> > > > >
> > > > > Aside from the runtime typesafe behaviour, Vector’s strong
> > typing means
> > > > > there is additional compile time support and, related, the
> > possibility
> > > of
> > > > > extra IDE support, both of which help the developer.
> > > > >
> > > > > Vector ‘types’ are also final ‘classes’ enforced by the
> > compiler, so
> > > > cannot
> > > > > be extended.
> > > > >
> > > > > Additionally, on looking closer, there are some other
> quirky
> > rules for
> > > > > runtime typing behaviour. These are related to the
> > implementation in
> > > AVM.
> > > > > The 3 Vector types for Vector.<int>, Vector.<uint>, and
> > Vector.<Number>
> > > > are
> > > > > individual base types, and then there is a 4th base type,
> > Vector.<*>
> > > > which
> > > > > serves as the ‘base class’ of all other Vector
> ‘subclasses’. The
> > 3
> > > > numeric
> > > > > types are faster than Array, and I expect this was the
> reason
> > for the
> > > > > separation, because these are used in a lot of other flash
> apis,
> > > > > particularly for swapping with byte level data and things
> like
> > > BitmapData
> > > > > etc. The others are more simply for the strong typing
> aspects,
> > because
> > > > > (perhaps less so with Boolean and String at a guess) they
> are
> > somewhat
> > > > > slower than Array in AVM, because of the overhead of
> runtime
> > > typechecking
> > > > > and coercions etc. So the main selling points for choosing
> a
> > Vector in
> > > > > flash were a) compile time and runtime type safety and b)
> faster
> > > > > performance for the 3 numeric Vector types.
> > > > >
> > > > > One implication of these ‘rules’ means that to check if
> > *something* is
> > > a
> > > > > Vector of any type in swf, I need to do (mything is
> Vector.<int>
> > ||
> > > > myThing
> > > > > is Vector.<uint> || myThing is Vector.<Number> || myThing
> is
> > > Vector.<*>)
> > > > or
> > > > > use reflection (which is slower).
> > > > >
> > > > > The above implies that, for language conformance
> (considered as
> > > > conformance
> > > > > with as3 documentation/spec and the behaviour of the
> reference
> > > > > implementation that we have for any ‘unknowns’) in an
> emulation,
> > a
> > > > regular
> > > > > single as3 class implementation would not create a result
> that is
> > > > > consistent with the spec in terms of its representation of
> > typing, and
> > > > its
> > > > > behaviour when using type checking.
> > > > >
> > > > > I tried to take all of these things into consideration.
> > > > >
> > > > >
> > > > >
> > > > > *How is it implemented in the branch?*
> > > > >
> > > > > Vector is implemented using the lightweight ‘synthType’
> approach
> > I
> > > added
> > > > > previously to support for int and uint types as ‘classes’.
> This
> > > provides
> > > > a
> > > > > light integration for ‘is’ and ‘as’ checks, but in
> javascript
> > itself a
> > > > > Vector instance is simply a tagged native javascript Array
> > instance
> > > (i.e.
> > > > > an Array with something that identifies it as being ‘not a
> > regular
> > > > Array’).
> > > > > The Array methods are enhanced at the instance level to
> support
> > the
> > > type
> > > > > coercions that take place in an actionscript Vector. Using
> Array
> > makes
> > > > > sense because Vector instances are essentially typed
> Arrays. But
> > it is
> > > > not
> > > > > possible to extend Array in javascript and have things work
> > properly
> > > (it
> > > > is
> > > > > possible to use a different approach with es6 Proxy, but
> that is
> > not
> > > > > available in IE11).
> > > > >
> > > > > This implementation also means that a ‘Vector’ instance
> should
> > have
> > > > > functionality that works mostly as expected if it is passed
> > directly to
> > > > a 3
> > > > > rd party native javascript library that is expecting an
> Array
> > instance.
> > > > It
> > > > > will not support errors when changing the length if the
> Vector
> > instance
> > > > is
> > > > > ‘fixed’ length, for example but otherwise it should
> function
> > much the
> > > > same
> > > > > as a regular Array in the 3rd party code.
> > > > >
> > > > > The ‘synthType’ approach can be used because Vector types
> are
> > final, so
> > > > it
> > > > > does not need to conform to a regular Royale class
> definition
> > that can
> > > be
> > > > > extended and can be much ‘lighter’. As with int and uint
> > ‘classes’, no
> > > > > Vector constructor exists until the first one is requested.
> > There is
> > > one
> > > > > internal private class in Language that provides most of
> the
> > > > functionality
> > > > > for Vector, and element coercion functions are generated
> > specifically
> > > for
> > > > > each Vector ‘subtype’. Overall, it behaves more like a
> subclass
> > > ‘factory’
> > > > > with each individual type’s constructor being created on
> demand
> > and
> > > > cached
> > > > > for future use.
> > > > >
> > > > > Reflection and serialization support have not been added
> yet,
> > but I
> > > > > certainly had these in mind also with this approach. I just
> > wanted to
> > > > reach
> > > > > a sensible intermediate point for now, and then add those
> in
> > later.
> > > > >
> > > > > In summary, the Vector implementation in the branch
> provides the
> > > > following:
> > > > >
> > > > > -distinct types (conforming in terms of type checking) for
> each
> > Vector
> > > > > subtype
> > > > >
> > > > > -lightweight integration with Language ‘is’ and ‘as’
> support
> > > > >
> > > > > -each Vector subtype has a unique constructor generated the
> > first time
> > > it
> > > > > is requested, the constructor does not exist prior to that.
> > > > >
> > > > > -expected to be compatible with 3rd party native
> javascript that
> > > expects
> > > > a
> > > > > regular javascript Array
> > > > >
> > > > > -serialization (amf) and reflection are not yet supported
> but
> > were
> > > > > considered, and that is planned as next steps.
> > > > >
> > > > > As at the time of writing, the current implementation is
> > supported by
> > > 300
> > > > > Vector-specific assertions that run side-by-side between
> > javascript and
> > > > swf
> > > > > in the manualtest UnitTests project. Apart from the
> differences
> > created
> > > > by
> > > > > explicitly switching off some type safety checks with
> > > > > @suppressvectorindexchecking, there is only one verifiable
> > difference
> > > in
> > > > > these tests between swf and javsacript. Probably there are
> things
> > > outside
> > > > > the test coverage that might need addressing still, but I
> think
> > it’s a
> > > > > pretty good start.
> > > > >
> > > > > These tests should be easily ported to framework level
> unit tests
> > > > > (RoyaleUnit) as the same approach has been used to add
> FlexUnit
> > tests
> > > in
> > > > > the past. Testing/Development is primarily in Chrome on
> windows,
> > but
> > > the
> > > > > same tests were subsequently verified on IE11, Edge, Opera
> and
> > Firefox
> > > on
> > > > > windows.
> > > > >
> > > > > *Implementation Info*
> > > > >
> > > > > *More quirks*
> > > > >
> > > > > A ‘fixed == true’ Vector cannot have its length changed.
> This
> > means
> > > that
> > > > > changes via the length setter and the mutation methods
> (push,
> > pop,
> > > shift,
> > > > > unshift etc) all throw errors if used when a Vector is
> ‘fixed ==
> > true’.
> > > > > But… splice method also can change length. And in AVM this
> works
> > even
> > > > with
> > > > > a fixed length Vector, which might possibly be a bug but
> is one
> > that is
> > > > > matched in the implementation to conform with flash.
> > > > >
> > > > > *Size impact.*
> > > > >
> > > > > Alex was concerned with size impact for HelloWorld because
> the
> > beads
> > > were
> > > > > using a Vector.<IBead> type in javascript in one of the
> > application
> > > > > framework base classes. But the requirement was for that to
> > simply to
> > > be
> > > > an
> > > > > Array in javascript, the compiler was only achieving that
> by
> > default
> > > > > because there was no real Vector implementation. So I did a
> > couple of
> > > > > things here. Firstly I changed the application framework
> code to
> > > reflect
> > > > > the different requirement for javascript. Secondly, I
> added some
> > doc
> > > > > comment directives to suppress exporting on public
> members. Then
> > I
> > > added
> > > > > this to the Language methods that are for
> compiler-generated
> > Vector
> > > (and
> > > > > int and uint) support so that they are eligible for dead
> code
> > > elimination
> > > > > if not used. This effectively means that it is fully PAYG
> – it
> > is only
> > > > > there if you need it, but if you need it there is also no
> effort
> > to add
> > > > it
> > > > > in as an optional dependency. If, because of this, there
> is a
> > potential
> > > > for
> > > > > issues with modules or something I have not thought of,
> that
> > will be
> > > > > another thing to solve, but if so, I will find a way to
> address
> > it.
> > > > >
> > > > > If the main concern with ‘size’ is data transfer, then
> looking
> > at the
> > > > > minified output size in HelloWorld is not really
> meaningful (or
> > perhaps
> > > > it
> > > > > is better to say that it is only as meaningful as looking
> at the
> > size
> > > of
> > > > an
> > > > > uncompressed swf compared to normal deployment of a
> compressed
> > swf). In
> > > > any
> > > > > real deployment the javascript should be served as
> gzipped. So I
> > > compared
> > > > > gzipped (‘normal’ compression) versions of HelloWorld.js
> between
> > those
> > > > with
> > > > > the unused Language support methods (for int/uint and
> Vector)
> > and their
> > > > > dependencies vs. builds without. The support for all that
> > functionality
> > > > > comes in at under 3 Kb difference in the gzipped output. I
> > personally
> > > > don’t
> > > > > think that would register as important in most cases.
> However,
> > it is
> > > > pretty
> > > > > close to zero impact now if it is not used. In fact the
> > HelloWorld
> > > > > application is now about 55 bytes smaller than it was
> before, so
> > I
> > > > consider
> > > > > it ‘carbon-netural’. And these are at the gzipped levels
> (it is
> > also
> > > > > slightly smaller when not gzipped, although it can
> sometimes be
> > the
> > > case
> > > > > that the larger of 2 files compresses better than a
> smaller one,
> > > > depending
> > > > > on the content).
> > > > >
> > > > > As a general comment about size… in my experience over the
> last
> > 10
> > > years
> > > > or
> > > > > so, mostly in relation to Flex apps, size was most often
> not
> > among the
> > > > > highest priority issues. Sure, start-up time often was.
> But that
> > is not
> > > > > size per se. Often ‘size’ issues were first and foremost
> ‘asset
> > size’
> > > > > issues (embedded or separate). While I know overall that it
> > remains
> > > > > important, I personally think the growth in bandwidth and
> device
> > memory
> > > > in
> > > > > general has outpaced the growth in the size of web apps
> even as
> > the
> > > world
> > > > > has turned to mobile. In other words, I think we probably
> passed
> > a
> > > hurdle
> > > > > point in the mobile side of things. Admittedly that is just
> > > ‘perception’
> > > > > and maybe there is data that shows I am quite wrong or your
> > experience
> > > on
> > > > > specific client projects could be quite different. The
> point of
> > me
> > > > > explaining that was, however, to illustrate why I think
> ‘size’
> > sits
> > > > where I
> > > > > think it does in general in terms of importance: I
> consider it
> > to be
> > > > behind
> > > > > stability/reliability first which is followed by
> performance in
> > > > performance
> > > > > critical code. Overriding that general flow (which again,
> is
> > just my
> > > > > opinion), are whatever my client’s specific requirements
> are for
> > any
> > > > > particular project. In other words I am not sure how much
> of
> > > HelloWorld’s
> > > > > size is going to be an important deciding factor for
> someone to
> > choose
> > > to
> > > > > use Royale. I think the ‘I got it to work!’ is the real
> kicker
> > here.
> > > This
> > > > > paragraph was not to cause any conflict, and I already
> addressed
> > the
> > > > ‘size’
> > > > > impact in the branch, so I’m not saying it wasn’t
> necessary to
> > do that
> > > > > (although I do suspect the same attention was not given to
> all
> > other
> > > > things
> > > > > in the past that affected HelloWorld). It’s more to promote
> > discussion
> > > > and
> > > > > thought in general. Trying to be all one aspect (small
> size) can
> > > > compromise
> > > > > other aspects (reliability or stability or compatibility,
> for
> > example).
> > > > And
> > > > > trying to accommodate all aspects (reliability, small size,
> > exceptional
> > > > > performance) somehow very likely increases complexity
> because
> > there is
> > > a
> > > > > need to accommodate the explicit decisions for trade-offs
> between
> > > > competing
> > > > > aspects. It would be good to have a guide of priorities
> based on
> > the
> > > > needs
> > > > > of the user base (while I might have a strong opinion
> about what
> > I
> > > think
> > > > is
> > > > > important, I don’t assume that my views necessarily
> represent
> > wider
> > > user
> > > > > needs, because I have not done research to support that –
> and
> > it’s not
> > > > > really a twitter poll kind of thing!). Anyhow I got off
> track
> > there a
> > > > bit…
> > > > > back to Vector…
> > > > >
> > > > >
> > > > >
> > > > > *Performance.*
> > > > >
> > > > > No-one should expect a non-native Vector implementation to
> > perform
> > > faster
> > > > > than native Array in javascript. Its main benefit is type
> > safety, and
> > > > that
> > > > > is the reason it should be selected for use over Array.
> (In swf,
> > native
> > > > > numeric Vector types *are* selected for performance, but
> the
> > other
> > > Vector
> > > > > types are also at least slightly slower than Array, so
> selecting
> > them
> > > is
> > > > > based on the need for type safety)
> > > > >
> > > > > There are, however some ways to get 100% Array performance
> with
> > this
> > > > > implementation, and in a loop, for example it would be
> similar to
> > > > avoiding
> > > > > method calls (like push/pop) and only using index
> assignments
> > that is
> > > > > typical of performance optimization in swf.
> > > > >
> > > > > So these two methods provide almost Identical performance
> in js:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > *private function testArrayInt2(iterations:uint):Number{
> var
> > > > start:Date
> > > > > = new Date(); var inst:Array = new Array(iterations);
> > for
> > > > (var
> > > > > i:uint=0;i<iterations; i++) { inst[i] = i; }
> > return new
> > > > > Date().valueOf() - start.valueOf(); } /** * *
> > > > > @royalesuppressvectorindexcheck true */ private function
> > > > > testVectorInt2(iterations:uint):Number{ var start:Date
> = new
> > > Date();
> > > > > var inst:Vector.<uint> = new Vector.<uint>(iterations);
> > for
> > > > > (var i:uint=0;i<iterations; i++) { inst[i] = i;
> }
> > > return
> > > > > new Date().valueOf() - start.valueOf(); }*
> > > > >
> > > > > The doc comment on the 2nd method prevented the compiler
> from
> > > generating
> > > > an
> > > > > index check wrapper around the ‘i’ in inst[i]
> > > > >
> > > > > The above 2 methods take around 5-7 ms for 500,000
> iterations on
> > my
> > > > machine
> > > > > (chrome/windows). This is quite a bit faster than the same
> > methods in
> > > the
> > > > > swf (non-debug) build on my machine. The Vector
> constructor is
> > also
> > > doing
> > > > > extra work in this case by setting all the 500,000 slots to
> > numeric 0.
> > > > But
> > > > > on modern browsers it is using a fast native Array.fill
> method
> > to do
> > > > that,
> > > > > so it’s probably more noticeable on IE11 which uses a for
> loop to
> > > > > pre-populate the contents with numeric 0 values.
> > > > >
> > > > > For reference, the generated code for the second method
> above,
> > looks
> > > like
> > > > > this:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > */** * * @royalesuppressvectorindexcheck true *
> @private *
> > @param
> > > > > {number} iterations * @return {number} */
> > > > >
> > > > >
> > > >
> > >
> >
> flexUnitTests.language.LanguageTesterTestVectorPerf.prototype.flexUnitTests_language_LanguageTesterTestVectorPerf_testVectorInt2
> > > > > = function(iterations) { var /** @type {Date} */ start =
> new
> > Date();
> > > > > var /** @type {Array.<number>} */ inst = new
> > > > >
> > (org.apache.royale.utils.Language.synthVector('uint'))(iterations);
> > > for
> > > > > (var /** @type {number} */ i = 0; i < iterations; i++) {
> > inst[i] =
> > > i;
> > > > > } return new Date().valueOf() - start.valueOf(); };*
> > > > >
> > > > > The methods with type checking in them, like push, unshift
> etc
> > will be
> > > > > quite a lot slower though. This should not be a surprise.
> In
> > swf, when
> > > > you
> > > > > look at something like Vector.<IBead> it can be up to 30%
> slower
> > than
> > > > Array
> > > > > for methods like push, iirc at native level. In javascript
> it
> > will be a
> > > > lot
> > > > > more. But in both cases it has type safety. And for small
> > collection
> > > > sizes
> > > > > in non-performance sensitive code it is probably not going
> to
> > make a
> > > > > meaningul difference.
> > > > >
> > > > > Known limitations
> > > > >
> > > > > 1. myVectorInstance[‘constructor’] can be different
> > between js
> > > and
> > > > > swf
> > > > >
> > > > > 2. There is some reliance on not obscuring the type
> from
> > the
> > > > compiler
> > > > > for things to work correctly. Example:
> > > > >
> > > > > var myObscuredType:* = new Vector.<String>(20,true) //
> creates a
> > fixed
> > > > > Vector of length 20
> > > > >
> > > > > myObscuredType.length = 21; //should throw an error, but
> does
> > not in
> > > > > javascript.
> > > > >
> > > > > This will work as long as the compiler knows that the type
> with
> > the
> > > > length
> > > > > setter is some type of Vector, otherwise not.
> > > > >
> > > > >
> > > > >
> > > > > *Performance tuning*
> > > > >
> > > > > *@royalesuppressvectorindexcheck*
> > > > >
> > > > > The above doc comment directive avoids checking for
> > out-of-valid-range
> > > > > index values on assignments. This is extremely desirable
> inside
> > loops
> > > > which
> > > > > are usually constrained to the valid range in any case.
> There is
> > a top
> > > > > level compiler configuration setting for this, but local
> > settings win
> > > > > (turning off or on generally with true/false, or
> suppressing
> > > specifically
> > > > > for individual local variable names)
> > > > >
> > > > >
> > > > >
> > > > > Other options.
> > > > >
> > > > > The above one was obvious to me as an important tuning
> option. I
> > > started
> > > > > with adding another but pulled it out in favor of adding
> them
> > based on
> > > > > actual need.
> > > > >
> > > > > There are many options:
> > > > >
> > > > > Instance based: reducing type checking with a compiler-only
> > generated
> > > > > additional constructor parameter, triggered by some doc
> comment
> > > > directive.
> > > > > This could be in the form of adding in compiler generated
> > alternatve
> > > > calls
> > > > > to things like ‘unsafePush’ and ‘unsafePop’ on instances,
> or
> > perhaps
> > > > > literal calls to Array.prototype.push.call(inst, pushItem),
> > triggered
> > > by
> > > > > some doc comment directive
> > > > >
> > > > > Global changes:Adding some compiler define value that
> (along
> > with:
> > > > > ||goog.DEBUG) suppresses many runtime checks in the release
> > Vector
> > > > > implementation. This would allow a blanket approach to
> dialing
> > runtime
> > > > > safety down (or keeping them) in the release build. It
> would
> > apply
> > > across
> > > > > all libraries and local project code.
> > > > >
> > > > > Some combinations of the above that allow sweeping
> optimizations
> > with
> > > > local
> > > > > exceptions.
> > > > >
> > > > > Basically, this branch currently represents what I have
> reason to
> > > believe
> > > > > is a high conformance Vector implementation which should
> be the
> > default
> > > > as
> > > > > it is an as3 core type. I think there are many options to
> scale
> > things
> > > > > back, but rather than assume what they should be, I’d
> prefer to
> > hear
> > > from
> > > > > users and address *real* needs, so that we only end up with
> > > configuration
> > > > > options that matter.
> > > > >
> > > > >
> > > > >
> > > > > *Advantages of a single Vector implementation – the case
> for
> > avoiding a
> > > > > ‘vector emulation class’*
> > > > >
> > > > > ‘Language emulation’ is a foundational layer that is not
> in the
> > same
> > > > > category as ‘application framework’ where we can define
> things
> > how we
> > > > want.
> > > > > Because the royale sdk includes both aspects inside
> ‘framework’
> > (and
> > > that
> > > > > was obviously not the case for flex sdk in the past) it
> may be
> > easy to
> > > > > overlook that difference.
> > > > >
> > > > > Vector typing is a core part of AS3 language. Therefore it
> should
> > > conform
> > > > > and be reliable. Having multiple implementations for a core
> > language
> > > > > feature seems wrong and could easily lead to libraries of
> code
> > that are
> > > > > incompatible. Additionally, as pointed out earlier, Vector
> is
> > more
> > > like a
> > > > > subclass factory (‘runtime’ generics) than a single class,
> so
> > won’t be
> > > > well
> > > > > represented by a regular class implementation.
> > > > >
> > > > > Alex, I know you added support for a Vector emulation class
> > approach to
> > > > > meet the needs of someone asking for improved Vector
> support, in
> > part
> > > > > because we did not have someone who had volunteered to
> write our
> > own. I
> > > > did
> > > > > that last part now. I am also suggesting that the
> emulation class
> > > > approach
> > > > > is not a good long term solution because of the above
> reasons.
> > And the
> > > > full
> > > > > set of functionality is less than 3Kb in the gzipped
> output, so
> > I’d
> > > > suggest
> > > > > that as long as I can add needs-based performance tuning
> options
> > for
> > > > those
> > > > > who want them, the benefits of having a single conforming
> > > implementation
> > > > > which is performance scalable are better than the risks
> > associated with
> > > > > adding partially non-conforming ones. Therefore I’d like
> to ask
> > if we
> > > can
> > > > > remove that functionality now that we have our own
> 'Vector' (I
> > can do
> > > the
> > > > > work if you prefer as I know your focus is understandably
> on
> > other
> > > > things).
> > > > >
> > > > > *Future:*
> > > > >
> > > > > It will be easily possibly to alter the current
> implementation
> > to use
> > > es6
> > > > > proxy which would likely provide the most reliable way to
> get
> > full
> > > Vector
> > > > > conformance indistinguishable from flash. Es6 proxy is
> > transparent for
> > > > > Array:
> > > > >
> > > > > var p = new Proxy(new Array(), {});
> > > > >
> > > > > Array.isArray(p) // true
> > > > >
> > > > > This should allow trapping things like the length setter
> before
> > it gets
> > > > to
> > > > > the underlying Array target, and doing checking for fixed
> ==
> > true etc.
> > > > The
> > > > > same is true for numeric index-based assignment of values
> etc.
> > > > >
> > > > > es6 Proxy is kinda cool. At the moment IE11 is the only
> > meaningful
> > > target
> > > > > that does not support this.
> > > > >
> > > > > I am only mentioning this here because I did think about
> this,
> > and I
> > > > > believe that the current implementation could be upgraded
> quite
> > easily
> > > to
> > > > > use this approach if it makes sense (when IE11 is a distant
> > memory –
> > > > > perhaps sometime next year!).
> > > > >
> > > > >
> > > > >
> > > > > Phew, you made it! Well done.
> > > > >
> > > > > Feel free to share your thoughts or ask any questions you
> might
> > have.
> > > If
> > > > > you have neither of those at this time, please still try
> to find
> > time
> > > to
> > > > > test any large projects you have in the branch, and provide
> > feedback or
> > > > > share any concerns you might have after doing that.
> > > > > thanks,
> > > > > Greg
> > > > >
> > > > >
> > > > > On Thu, May 23, 2019 at 7:55 PM Greg Dove <
> greg.dove@gmail.com>
> > wrote:
> > > > >
> > > > > > Re XMLTest manualtest...
> > > > > >
> > > > > > Yep those were the ones I ported, Harbs. I think I got
> them
> > all but
> > > may
> > > > > > have missed some. I added a bunch more as well. Hopefully
> > these can
> > > be
> > > > > > easily migrated to what Josh has been working on.
> > > > > >
> > > > > >
> > > > > > On Thu, 23 May 2019, 19:43 Harbs, <harbs.lists@gmail.com
> >
> > wrote:
> > > > > >
> > > > > >> As far as XML unit tests go, the starting point should
> be
> > XMLTest in
> > > > > >> manual tests. (Almost) every time I ran into an issue, I
> > added it to
> > > > > that
> > > > > >> project.
> > > > > >>
> > > > > >> I think I might have been lax on the last few issues I
> fixed,
> > so we
> > > > > >> should probably go through the later XML commits and
> make
> > sure we
> > > have
> > > > > >> tests for that.
> > > > > >>
> > > > > >> As far as Node goes, I think we probably need
> conditional Node
> > > > > >> compilation to handle Node-specific (and browser
> specific)
> > code in a
> > > > > PAYG
> > > > > >> way.
> > > > > >>
> > > > > >> To technically handle the parsing, something like
> > > > > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0
> > <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0
> > >
> > > > is
> > > > > a
> > > > > >> good starting point and something like this
> > > > > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0
> > <
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0
> > >
> > > > > >> might be useful to either use or modify.
> > > > > >>
> > > > > >> Harbs
> > > > > >>
> > > > > >> > On May 23, 2019, at 10:18 AM, Greg Dove <
> > greg.dove@gmail.com>
> > > > wrote:
> > > > > >> >
> > > > > >> > All, I started porting some adhoc XML tests to
> UnitTests and
> > > > > eventually
> > > > > >> > ended up spending quite a bit of time on addressing
> issues
> > that
> > > > arose
> > > > > >> for
> > > > > >> > XML before getting back to Vector stuff.
> > > > > >> > I think XML probably needs many more unit tests
> before we
> > get to
> > > 1.0
> > > > > >> > because it has an extensive api. I have not used
> royale
> > with Node
> > > > yet,
> > > > > >> but
> > > > > >> > XML also needs some thought about how to get it
> working on
> > Node, I
> > > > > >> assume.
> > > > > >> > Because XML uses the browser's parser and Node does
> not
> > have one
> > > by
> > > > > >> > default, then using the same code will need something
> to
> > take the
> > > > > place
> > > > > >> of
> > > > > >> > the browser's native parser for Node. There is a lib
> in npm
> > that
> > > > might
> > > > > >> be
> > > > > >> > useful for that, but I don't know how that might work
> with
> > licence
> > > > > etc.
> > > > > >> > Anyhow, that is just an observation, I will focus on
> Vector
> > in
> > > this
> > > > > >> > thread... I will post here late tomorrow local time
> with
> > more
> > > info,
> > > > > and
> > > > > >> > discussion points. I am keen to see this merged in,
> but
> > also keen
> > > to
> > > > > get
> > > > > >> > buy-in first.
> > > > > >> >
> > > > > >> >
> > > > > >> > On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <
> > > > > carlosrovira@apache.org
> > > > > >> >
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> >> 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.dove@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.dove@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
> > > > <aharui@adobe.com.invalid
> > > > > >
> > > > > >> >>>> wrote:
> > > > > >> >>>>
> > > > > >> >>>>> +1 to renaming the options to the positive.
> > > > > >> >>>>>
> > > > > >> >>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <
> > joshtynjala@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.dove@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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=vC7Sy%2BfGwJhbS8bR0Eo4wZBTNxsuEGCWXQ6nHceAk18%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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=NlTd48QGPtLVuoxX%2Fv4IO0ZZyz3CMgh7Gzllr3D%2BIoA%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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=dwgAt0Rz%2Bt575HRIk97kPbtewGN4mSv8FbCQr6Skudg%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
> > > > > >> >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0
> > > > > >> >>
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0
> > >
> >
> >
> >
>
>
>
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
Alex, I made some comments inline below...
On Thu, May 30, 2019 at 9:47 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> We must not eliminate choices.
>
> I still haven't had time to look at the branch.
>
> There must be away to avoid even a 1K cost to those who don't need it.
>
> If there is such a way, then it is fine to merge. Otherwise, everyone is
> going to pay 2K to use a Vector when we know at least two apps are in
> production without needing that 2k.
>
> There are too many words being written and no technical points being
> made. I will try to resummarize.
>
As I have said, my concerns are not technical.
>
> 1) It does not matter how fast your network is. Every other app will use
> more bandwidth and when the network gets busy or connectivity gets poor
> (something I see quite frequently where I live) either you get your app to
> run or you run out of time.
>
>
The only thing that seems particularly relevant for this discussion is how
long it takes for the 'app' to load when it is not already in browser cache.
I wholeheartedly agree that what I think about this in terms of the general
case is irrelevant if whoever is specifying the requirements for a
particular app says that incremental gains at 2KB or 1KB is what is
important to them (for any reason).
I'm not saying this is never important, I was just trying to explain how I
think of it in terms of why I prioritize things (by default) the way I do.
If we spent too much time and effort on meeting the needs of the few we may
under-represent the needs of the many. Without independent research neither
of us can be sure what the needs of the many are, so I am not going to
pursue this point any further.
2) If you are not using some feature of our code, you should not have to
> pay for it in download cost. That's PAYG. That would be true for Vector,
> XML and even if we had to write a Date implementation. It is not an issue
> of non-conforming. It is an issue of optimization. If you aren't going to
> use some feature of E4x you should have the option of using code that
> doesn't have those code paths. Same for if we had to do Date.
>
The only safe way to do what you propose that I can think of is to make
sure nothing of these alternate emulation classes is *ever* baked into a
swc and that any 'lite' version specified at the main application build
level wins for everything. I can see how this could be done for XML but I
don't see that easily for the 'emulation class' approach to Vector which I
think is the wrong way to achieve this.
> We know that if you don't need runtime-type checking and fixed-length
> checking that a plain Array is just fine and 2K cheaper. Let's give folks
> the option to do that.
>
>
I think, as with others, that a new compile-time only typed Array is the
better way to do that. We can specify it as compiletime only and it will
never break the rules that we specify.
I will repeat that I do not have any objection to having a full Vector
> implementation with runtime type-checking and fixed length checking be the
> default choice as long as folks can optimize back to using the plain Array
> code we use now.
>
> I do understand your position. I don't agree with the plain Array output
option for Vector, but as I mentioned if it is a majority decision I will
make sure it is supported.
I think the better option for the need you describe is the new typed Array
feature discussed by others.
For the one Vector we currently have in all apps for the Strand, it might
> be time to change that to an array and check the type (in debug-only code)
> on addBead. Either that or we add compiler options so that one Vector gets
> optimized to the current plain Array code.
>
>
I already did exactly that in the branch. Vector has zero weight in
helloworld because it is not used in javascript.
I kept swf as it was, but I don't think there is any real value in keeping
that as vector in swf either, tbh. The addBead method is the only way to
put things into that as far as I can see, and the function signature
already gives you runtime type safety in that case in swf. Vector provides
no performance advantage over Array in swf in this case, and there is no
compiletime typesafety advantage. It might make sense to migrate both to a
common implementation as Array instead of having split code (which I can
look at later).
> It is not a technical argument to classify Vector as "Language" and
> therefore somehow an exception to being optimizable.
>
>
I have never intended to imply that. If "Language" is optimizable without
the risk of bad consequences, that is fine by me.
But "Language" must work as advertised when exposed to anyone who has no
reason to think otherwise, and an 'optimized' version which does not do so
in that case is 'dangerous', and will tarnish royale's reputation in my
view. The biggest risks I see are if something non-conforming is exposed in
a public swc library either directly via api, or via access through
inheritance, but there could be other scenarios.
In the absence of issues like that for "Language" I think it optimization
is fair game.
In fact, I can shave another 500 bytes off gzipped HelloWorld by making
some the Language stuff you added for Array sort/sortOn go away because it
is never used in HelloWorld, using the same approach I have for Vector.
> My 2 cents,
> -Alex
>
>
> On 5/28/19, 2:59 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi,
>
> I think that we all agree in most of the things, and although we're
> discussing some particularities on how to solve, my opinion is that
> those
> particularities can be solved after merging Language improvements
> branch.
> We all agree we need this Vector (and other improvements in this
> branch)?.
> So, after that merge folks wanting to improve, let's say, Vector(for
> example) even more with new choices can do that without problem and
> will
> make it even better.
>
> Are we ok with that?
>
>
>
>
>
> El mar., 28 may. 2019 a las 11:07, Harbs (<ha...@gmail.com>)
> escribió:
>
> >
> > > On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com>
> wrote:
> > >
> > >> "I personally have never used length checking in Vector. Nor was
> runtime
> > >> type checking on Vectors important to me. "
> > > length checking is automatic in flash. I don't know that you 'use'
> it...
> > it
> > > is just there.
> >
> > True. What I meant is that I never used fixed length Vectors.
> >
> > > In javascript I expect it would most often be switched off in all
> release
> > > builds, but having it on by default provides another check of
> something
> > > that could provide a vital clue to help people figuring out
> problems in
> > > code.
> > > So far each 'stronger typing' feature added in the last few months
> has
> > > revealed potential issues or - most often - bad code that was
> working
> > when
> > > it should not
> >
> > Good points, and one that argues for the ability to have these checks
> > while debugging and have the run-time code removed on release.
> >
> > > One thing about the mxml stuff is that it gets processed in a way
> that is
> > > untyped.
> >
> >
> > Agree. I do wish there was some way for MXML to be output “better”
> where
> > minified vars could “just work” and types could be better inferred
> from the
> > MXML files.
>
>
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce8d86e6cf4aa4271e8ad08d6e35326eb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636946343611259722&sdata=g8BXA5jwwT98fAbwdMR2FqmJ3CgKd01zsm1lpt5pTDg%3D&reserved=0
>
>
>
Re: Language improvements
Posted by Alex Harui <ah...@adobe.com.INVALID>.
We have an implementation/optimization now that works for many people. Greg has another implementation that will work for some other people. He is free to add it as an option and make it the default option. It would be wrong to take away the current option. I can't think of any good reason to throw away working code that is smaller.
PAYG, choices. That's what we've been doing in Royale/FlexJS since the beginning. IMO, the option could have easily been implemented in the time we've spent on this thread. And probably significant progress would have been made on Vector and AMF.
-Alex
On 5/31/19, 2:51 PM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
don't think is one thing or another. I think there's a disagreement here.
Your point is one: give options event at the language level. Greg has
another point, that seems valid too (at least to me), not give options at
language level *at least in this iteration*. Nobody is saying this could
not be done in the future.
My opinion in this case is go with this and left that optimization for the
future. For sure others could have other opinions too. People needs this
new Vector implementation. We need it for use in our real production app
with AMF updates (implemented next and based on this work). I think we all
can have what we want, with this simple plan:
1.- Merge now Language improvements from Greg
2.- Continue working on Vector
a) Greg wants to add AMF support as next step
b) you want to make it a choice, you can do this as your next step
too.
Result: We all win. We all have what we want.
If we don't go. We have a problem, since people like me can't progress in a
feature we need to add in our real production app. Maybe others too. I
think that's not good. And I want to have choices too, but I can wait to
improve Vector implementation more to get to that, since priority, at least
for me, is to have support for Vector in AMF/ RemoteObject.
So I think we should not discuss more on the points we discussed largely in
this thread and we all know how we all think right? I think we need a plan
to execute. I think is the most practical thing we can do right now.
Do you find any problem in making this way based on the points I described
before? If not, let us know what could be your plan / steps to do (but
please, describe something doable, since if not we continue stuck in an
endless discussion).
Thanks in advance for your help.
El vie., 31 may. 2019 a las 22:26, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Greg, you are still trying to use the language conformance argument. This
> is not an issue of language conformance, it is an issue of optimization.
> Code paths not needed should not be downloaded. Every app development tool
> I've used that offers optimizations offers optimization levels and
> documentation of risks.
>
> There is a disagreement on how to implement Vector in JS as well. The
> whole point of giving choices is to avoid having to spend so many emails
> trying to reach a decision. Just provide choices so we can move on. Every
> argument you make below is an argument for giving choices.
>
> -Alex
>
> On 5/30/19, 9:03 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> "And so we will stop using Vector and migrate to using a plain Array.
> That
> agreement proves that the proposed changes are not right." We will
> effectively encourage others to do the same.
>
> It does not prove that at all, Alex. It depends on the criteria, and we
> have no commonly accepted guiding principles for what is 'right' here.
> At least one of us believes that it is more correct that (in the
> absence of
> other proposed options) it be an Array in the original code.
> If you take a step back and look at it from a broader perspective, it
> can
> be equally true to say 'This agreement proves that the original
> implementation was not right'.
> Firstly, I don't think Vector type was providing any benefit in this
> case
> in the first place (but that alone is not a reason to change it,
> awareness
> that it 'costs more' would however be a valid reason if there are no
> benefits to using it).
> Secondly, the collaborative outcome resulting in the use of explicit
> Array
> and the goog.DEBUG check is better than the original Vector-as-Array
> output
> because it offers the runtime type safety that was missing because it
> was
> not behaving like a Vector - and it retains the advantage of
> zero-weight in
> release build. Making these changes *is* a form of optimization based
> on
> using options currently available, it just happens to be hand-coded
> and not
> compiler-generated.
> I know it's at least a little bit useful in its new form, because prior
> testing with the branch level Vector implementation flagged a
> non-conforming IBead in the 2nd app I tested it with, something that
> was
> not found by the original 'Array' implementation.
> SWF testing in parallel would have caught that too, but is not a
> realistic
> assumption to have that as part of the workflow for checking runtime
> behavior anymore, so this 'Array with debug-only typecheck' in
> javascript
> is a good outcome.
> In this case, going back to Vector-as-Array output without making the
> other
> change would be a step backwards.
>
> That is however just one specific case, and I needed to present what I
> believe is a more balanced view of that... but I will not focus on it
> in
> any further discussion.
> I do understand that your point is intended to be more general.
> In general, and *by definition*, the cases where you want Vector to be
> Array without adverse consequences are always cases where it can also
> *be*
> Array in the original as3 code. If the only justification for it being
> a
> Vector in as3 code is 'compile-time type safety', then the proposed
> alternative from Harbs and Josh is a better option because it retains
> the
> benefits you seek and is a better quality cross-target representation
> for
> this specific sort of requirement (it will also provide more benefits:
> most
> Vector methods do not have compile-time type safety because most their
> method signatures do not specify :T types, I hope the proposed
> alternative
> might address that).
> For the performance-oriented numeric types, which is another thing
> that has
> been raised, maybe Josh can somehow include that with the typed Arrays
> feature as he suggested, maybe not. If yes, then great, but if not, I
> am
> happy to explore other options for that.
>
> What I'd really like to hear are your thoughts about the concerns I
> raised
> for the:
> "new whateverclasstheconfigordirectivespecified()"
> approach to doing any of this.
>
> How do you propose to avoid risk to the community and potentially to
> Royale's reputation with release of swcs that can have different
> language-level variations in them (XML, Vector or anything that
> represents
> a core as3 'type')?
> Do we have to warn people not to do that, and then hope that they
> don't? A
> user of that swc doesn't see the emulation class that the swc may
> expose
> without investigating at runtime, they normally only see the type it
> represents, and unless they are warned, they have no reason to assume
> it
> won't do all the things it should. There could also be runtime conflict
> implications when mixing swcs with different emulation decisions, and
> that
> could even add weight overall compared to using one. None of this
> represents stuff that can't be figured out and addressed by developers
> who
> have to deal with it. But it seems to me to be something negative,
> which
> would be better to avoid.
>
> I think you are indicating the same desire to avoid this problem by
> saying
> that you want to specify things by 'the swc' you add (e.g. XML
> replacement)... but that can be too late, because even if an alternate
> emulation class itself is not bundled into a swc's code, all the calls
> to
> instantiate it are, which reflect its distinct package name and class
> name.
> I can envisage ways to achieve optimization and to avoid risks for the
> general case, but only if the instantiation calls for these language
> level
> emulations can never vary throughout the entire codebase (all swcs
> included), and the 'optimization' is therefore largely driven from the
> application build, and not dictated at swc level. Maybe swc libraries
> could
> be advertised as being compatible with some well-known optimizations in
> this case, it could even be a 'marketing' claim for the swc.
> The most appealing optimization solution (to me) would be one that
> takes
> more advantage of GCC (which I consider will be 'safer', and also least
> effort for the developer) when the application gets built, instead of
> actually changing the content of individual methods (for example) in
> 'lite'
> versions of replacement classes. However, I can see that doing the
> latter
> (or both) should also be possible and should not be much different, I
> think, from a regular monkey-patch approach, or from your desire for
> swc
> level replacement - but it only works if there is no variation in the
> actual naming of the classes that are being 'patched' (whether its via
> an
> alternate XML-like swc as a direct substitute for the standard one, or
> a
> local monkey patch). Maybe I'm missing something that is obvious to
> you...
> please tell me if I am.
>
>
> On Fri, May 31, 2019 at 6:37 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > It is pretty simple to me. The proposed Vector implementation is
> heavy
> > enough that we all agree that we don't want to use it for just one
> use case
> > in the Strand. And so we will stop using Vector and migrate to
> using a
> > plain Array. That agreement proves that the proposed changes are not
> > right. We will effectively encourage others to do the same.
> >
> > It would be much better if Royale had a way for developers to
> specify that
> > the one use of Vector in the Strand should be converted to plain
> Array by
> > the compiler and other uses could use the proposed Vector. That's
> how
> > optimization should be made available for all kinds of code in
> Royale, not
> > just for Vector.
> >
> > The current Vector output in the develop branch is low cost and fully
> > functional for some uses cases. As long as that output is still
> available
> > as a compiler option then having other output fine.
> >
> > I still haven't found time to look at the actual proposed changes,
> but I
> > would strongly prefer that, instead of having to modify compiler
> output
> > each time someone proposes a different Vector implementation, that
> the
> > changes can all be done by which SWC you choose for your Vector
> > implementation. There are other places in the compiler where you can
> > choose the class to use for Binding or ClassFactory. Hopefully the
> same
> > approach is being used for Vector. Ideally, the compile would just
> output
> > "new whateverclasstheconfigordirectivespecified()" and then just
> output the
> > usual push/pop/index calls and so it could just be plain Array where
> > specified or the proposed Vector and some other Vector someday.
> >
> > This is a case were "there is no one right way". And when we have
> those
> > situations, we must offer choices.
> >
> > -Alex
> >
> > On 5/30/19, 1:34 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > Hi,
> >
> > @Alex Harui <ah...@adobe.com> I think you misunderstood me.
> I'm not
> > saying
> > we should "remove choices". What I say is that we have finally a
> more
> > robust implementation and we can evolve to have more choices
> from that
> > point. I think continue from that safe point will give us many
> > benefits. So
> > I want those choices. What I don't want is to wait to make it
> perfect
> > to
> > merge. As I said before perfection is enemy of the progress.
> >
> > An important point I can't agree with you: Why we don't use
> Vector in
> > our
> > production App? Cause we can't. To do that we need: a) Greg
> changes
> > merged,
> > b) make AMF understand Vectors (still to be done to make Vector
> usable
> > for
> > us). Without both points Vectors are not an option for us. So I
> think
> > the
> > premise of "we have 2 apps in production without Vectors" are not
> > right. We
> > don't have still Jewel DataGrid, or Swiz Global Dispatcher, and
> that
> > does
> > not mean it's ok for us. Is just we still don't have it, but
> making us
> > to
> > make our product without all of that is a serious issue that we
> need to
> > workaround in some way. But we can do that as something
> "temporal",
> > due to
> > current Royale limitations. But our goal is to have all that,
> > Vector-AMF
> > included :)
> >
> > For this reason, I prefer to have Greg's Vector now, since it
> makes our
> > production App be one step closer to remove current workarounds
> :)
> > And I'm sure that not having a Vector solution like this, could
> be a
> > reason
> > why some people still didn't try Royale to migrate to this date.
> > So if you ask me or those people for a "priority path", we will
> say
> > "let's
> > get Vector first, then evolve from that to have more choices".
> > That's what I'm saying it's ok to merge now.
> >
> > I'm ok with having Vector as we all know it from AS3 (since is
> > that...AS3
> > Vector, don't forget that, and is what people expect to have at
> first
> > sight, then we can give them more choices and they will
> appreciate for
> > sure), and have as well a new Typed Array too as other proposed
> too.
> > That
> > will be for me options. But we should not wait to make all that
> happen
> > to
> > merge current branch, right?, All that we'll be lots of time to
> make it
> > perfect from day 0.
> >
> > The key concept for me was what Harbs said in his response to
> the end.
> > If
> > you don't use it the impact is 0, not 2-3k, since people don't
> have
> > Vector
> > presence in their codes. So that's PAYG. For that reason it's ok
> for
> > me to
> > merge and continue from that safe point, since we really only get
> > positive
> > things and nothing negative, and since we all agree in the same
> terms,
> > just
> > we need more time to continue evolving it to get to that perfect
> final
> > point.
> >
> >
> >
> >
> > El jue., 30 may. 2019 a las 7:56, Greg Dove (<
> greg.dove@gmail.com>)
> > escribió:
> >
> > > Harbs some quick comments inline...
> > >
> > > On Thu, May 30, 2019 at 4:27 PM Harbs <ha...@gmail.com>
> wrote:
> > >
> > > > The only niggle I have with my approach is that Vector in
> Flash is
> > more
> > > > performant than array, while in JS, it’s going to be the
> other way
> > > around.
> > > > So if someone has a performance-sensitive piece of code, how
> > should they
> > > > write it so it outputs as performant as possible on both
> platforms?
> > > >
> > > > Vector in flash is only substantially faster for its 3
> numeric
> > types
> > > which
> > > are optimized. It is (slightly) slower than Array in other
> cases - I
> > think
> > > it is normal that the extra type checking takes time even in
> native
> > code.
> > > I remember seeing some data which said it was 30% slower for
> some
> > methods
> > > with the non-primitive types, but that may be old.
> > >
> > > In terms of the emulation version, you can get javascript Array
> > speed with
> > > the index access and assignment, which should be a direct copy
> of
> > the same
> > > parts of code that are heavily optimized in flash I think.
> > >
> > > I was running performance tests on the non-debug flash player
> > alongside
> > > javascript. I actually see the regular native javascript Array
> > beating
> > > flash numeric Vectors in Chrome on windows, for the same tasks.
> > Perhaps the
> > > pepper plugin is getting less cpu resource than the browser or
> > something
> > > like that, not sure. I had assumed TypedArrays would be
> faster, but
> > > recently you said you weren't sure because of js engine
> smarts. I
> > will
> > > still check that.
> > >
> > >
> > >
> > > > I have not spent the time looking into the implementation,
> but I
> > think
> > > > there might be some cross-communication. My understanding
> from
> > what Greg
> > > > wrote is that if Vector is not used in an application, there
> will
> > be no
> > > > extra code due to dead code removal. If that’s correct, I
> think
> > we’re in
> > > > agreement that the implementation is fine. Do I understand
> > correctly?
> > > >
> > >
> > > That is correct.
> > >
> > >
> > > >
> > > > Harbs
> > > >
> > > > > On May 30, 2019, at 1:26 AM, Josh Tynjala <
> > joshtynjala@apache.org>
> > > > wrote:
> > > > >
> > > > > I definitely want the default choice to have as few
> surprises as
> > > > possible when it comes to how ActionScript behaves in Royale.
> > We'll never
> > > > have a perfect emulation, of course, but there are things
> that I
> > think
> > > can
> > > > still be improved. At the same time, I think it's perfectly
> valid
> > for
> > > > someone to want to opt into a typed Array that doesn't have
> the
> > runtime
> > > > overhead of Vector and isn't as heavy in file size. I'm wary
> of the
> > > > solution being a custom implementation of Vector with missing
> > features,
> > > > though. It will lead to confusion, even if it's opt-in.
> > > > >
> > > > > What Harbs suggested seems like a smart way to go. Rather
> than
> > having a
> > > > separate Vector implementation that doesn't work as
> developers are
> > used
> > > to,
> > > > a new variation of Array that has compile-time type checks
> but no
> > runtime
> > > > checks sounds like a more elegant solution. Like Vector
> works in
> > Royale
> > > > today, it can compile down to a regular JS Array, but at
> > compile-time,
> > > we'd
> > > > have some extra safety and could even possibly cast back and
> forth
> > with
> > > > untyped Arrays (which we can't do with Vector).
> > > > >
> > > > > - Josh
> > > > >
> > > > > On 2019/05/29 18:07:31, Alex Harui
> <ah...@adobe.com.INVALID>
> > wrote:
> > > > >> We must not eliminate choices.
> > > > >>
> > > > >> I still haven't had time to look at the branch.
> > > > >>
> > > > >> There must be away to avoid even a 1K cost to those who
> don't
> > need it.
> > > > >>
> > > > >> If there is such a way, then it is fine to merge.
> Otherwise,
> > everyone
> > > > is going to pay 2K to use a Vector when we know at least two
> apps
> > are in
> > > > production without needing that 2k.
> > > > >>
> > > > >> There are too many words being written and no technical
> points
> > being
> > > > made. I will try to resummarize.
> > > > >>
> > > > >> 1) It does not matter how fast your network is. Every
> other
> > app will
> > > > use more bandwidth and when the network gets busy or
> connectivity
> > gets
> > > poor
> > > > (something I see quite frequently where I live) either you
> get
> > your app
> > > to
> > > > run or you run out of time.
> > > > >>
> > > > >> 2) If you are not using some feature of our code, you
> should
> > not have
> > > > to pay for it in download cost. That's PAYG. That would be
> true
> > for
> > > > Vector, XML and even if we had to write a Date
> implementation. It
> > is not
> > > > an issue of non-conforming. It is an issue of
> optimization. If
> > you
> > > aren't
> > > > going to use some feature of E4x you should have the option
> of
> > using code
> > > > that doesn't have those code paths. Same for if we had to
> do Date.
> > > > >>
> > > > >> We know that if you don't need runtime-type checking and
> > fixed-length
> > > > checking that a plain Array is just fine and 2K cheaper.
> Let's
> > give
> > > folks
> > > > the option to do that.
> > > > >>
> > > > >> I will repeat that I do not have any objection to having
> a full
> > Vector
> > > > implementation with runtime type-checking and fixed length
> > checking be
> > > the
> > > > default choice as long as folks can optimize back to using
> the
> > plain
> > > Array
> > > > code we use now.
> > > > >>
> > > > >> For the one Vector we currently have in all apps for the
> > Strand, it
> > > > might be time to change that to an array and check the type
> (in
> > > debug-only
> > > > code) on addBead. Either that or we add compiler options so
> that
> > one
> > > > Vector gets optimized to the current plain Array code.
> > > > >>
> > > > >> It is not a technical argument to classify Vector as
> "Language"
> > and
> > > > therefore somehow an exception to being optimizable.
> > > > >>
> > > > >> My 2 cents,
> > > > >> -Alex
> > > > >>
> > > > >>
> > > > >> On 5/28/19, 2:59 AM, "Carlos Rovira" <
> carlosrovira@apache.org>
> > > wrote:
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I think that we all agree in most of the things, and
> > although we're
> > > > >> discussing some particularities on how to solve, my
> opinion
> > is that
> > > > those
> > > > >> particularities can be solved after merging Language
> > improvements
> > > > branch.
> > > > >> We all agree we need this Vector (and other
> improvements in
> > this
> > > > branch)?.
> > > > >> So, after that merge folks wanting to improve, let's
> say,
> > > Vector(for
> > > > >> example) even more with new choices can do that without
> > problem and
> > > > will
> > > > >> make it even better.
> > > > >>
> > > > >> Are we ok with that?
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> El mar., 28 may. 2019 a las 11:07, Harbs (<
> > harbs.lists@gmail.com>)
> > > > escribió:
> > > > >>
> > > > >>>
> > > > >>>> On May 28, 2019, at 11:12 AM, Greg Dove <
> greg.dove@gmail.com>
> > > wrote:
> > > > >>>>
> > > > >>>>> "I personally have never used length checking in
> Vector. Nor
> > was
> > > > runtime
> > > > >>>>> type checking on Vectors important to me. "
> > > > >>>> length checking is automatic in flash. I don't know
> that you
> > 'use'
> > > > it...
> > > > >>> it
> > > > >>>> is just there.
> > > > >>>
> > > > >>> True. What I meant is that I never used fixed length
> Vectors.
> > > > >>>
> > > > >>>> In javascript I expect it would most often be switched
> off in
> > all
> > > > release
> > > > >>>> builds, but having it on by default provides another
> check of
> > > > something
> > > > >>>> that could provide a vital clue to help people figuring
> out
> > problems
> > > > in
> > > > >>>> code.
> > > > >>>> So far each 'stronger typing' feature added in the last
> few
> > months
> > > has
> > > > >>>> revealed potential issues or - most often - bad code
> that was
> > > working
> > > > >>> when
> > > > >>>> it should not
> > > > >>>
> > > > >>> Good points, and one that argues for the ability to have
> these
> > checks
> > > > >>> while debugging and have the run-time code removed on
> release.
> > > > >>>
> > > > >>>> One thing about the mxml stuff is that it gets
> processed in a
> > way
> > > > that is
> > > > >>>> untyped.
> > > > >>>
> > > > >>>
> > > > >>> Agree. I do wish there was some way for MXML to be output
> > “better”
> > > > where
> > > > >>> minified vars could “just work” and types could be better
> > inferred
> > > > from the
> > > > >>> MXML files.
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Carlos Rovira
> > > > >>
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca5d2bf322f6f4fc516fd08d6e61223ca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636949363104909263&sdata=jiO6laah7%2BQJco8dZGD76QWu93eJzPLGpsPRT66GoPg%3D&reserved=0
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca5d2bf322f6f4fc516fd08d6e61223ca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636949363104909263&sdata=jiO6laah7%2BQJco8dZGD76QWu93eJzPLGpsPRT66GoPg%3D&reserved=0
> >
> >
> >
>
>
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca5d2bf322f6f4fc516fd08d6e61223ca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636949363104909263&sdata=jiO6laah7%2BQJco8dZGD76QWu93eJzPLGpsPRT66GoPg%3D&reserved=0
Re: Language improvements
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
don't think is one thing or another. I think there's a disagreement here.
Your point is one: give options event at the language level. Greg has
another point, that seems valid too (at least to me), not give options at
language level *at least in this iteration*. Nobody is saying this could
not be done in the future.
My opinion in this case is go with this and left that optimization for the
future. For sure others could have other opinions too. People needs this
new Vector implementation. We need it for use in our real production app
with AMF updates (implemented next and based on this work). I think we all
can have what we want, with this simple plan:
1.- Merge now Language improvements from Greg
2.- Continue working on Vector
a) Greg wants to add AMF support as next step
b) you want to make it a choice, you can do this as your next step
too.
Result: We all win. We all have what we want.
If we don't go. We have a problem, since people like me can't progress in a
feature we need to add in our real production app. Maybe others too. I
think that's not good. And I want to have choices too, but I can wait to
improve Vector implementation more to get to that, since priority, at least
for me, is to have support for Vector in AMF/ RemoteObject.
So I think we should not discuss more on the points we discussed largely in
this thread and we all know how we all think right? I think we need a plan
to execute. I think is the most practical thing we can do right now.
Do you find any problem in making this way based on the points I described
before? If not, let us know what could be your plan / steps to do (but
please, describe something doable, since if not we continue stuck in an
endless discussion).
Thanks in advance for your help.
El vie., 31 may. 2019 a las 22:26, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Greg, you are still trying to use the language conformance argument. This
> is not an issue of language conformance, it is an issue of optimization.
> Code paths not needed should not be downloaded. Every app development tool
> I've used that offers optimizations offers optimization levels and
> documentation of risks.
>
> There is a disagreement on how to implement Vector in JS as well. The
> whole point of giving choices is to avoid having to spend so many emails
> trying to reach a decision. Just provide choices so we can move on. Every
> argument you make below is an argument for giving choices.
>
> -Alex
>
> On 5/30/19, 9:03 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> "And so we will stop using Vector and migrate to using a plain Array.
> That
> agreement proves that the proposed changes are not right." We will
> effectively encourage others to do the same.
>
> It does not prove that at all, Alex. It depends on the criteria, and we
> have no commonly accepted guiding principles for what is 'right' here.
> At least one of us believes that it is more correct that (in the
> absence of
> other proposed options) it be an Array in the original code.
> If you take a step back and look at it from a broader perspective, it
> can
> be equally true to say 'This agreement proves that the original
> implementation was not right'.
> Firstly, I don't think Vector type was providing any benefit in this
> case
> in the first place (but that alone is not a reason to change it,
> awareness
> that it 'costs more' would however be a valid reason if there are no
> benefits to using it).
> Secondly, the collaborative outcome resulting in the use of explicit
> Array
> and the goog.DEBUG check is better than the original Vector-as-Array
> output
> because it offers the runtime type safety that was missing because it
> was
> not behaving like a Vector - and it retains the advantage of
> zero-weight in
> release build. Making these changes *is* a form of optimization based
> on
> using options currently available, it just happens to be hand-coded
> and not
> compiler-generated.
> I know it's at least a little bit useful in its new form, because prior
> testing with the branch level Vector implementation flagged a
> non-conforming IBead in the 2nd app I tested it with, something that
> was
> not found by the original 'Array' implementation.
> SWF testing in parallel would have caught that too, but is not a
> realistic
> assumption to have that as part of the workflow for checking runtime
> behavior anymore, so this 'Array with debug-only typecheck' in
> javascript
> is a good outcome.
> In this case, going back to Vector-as-Array output without making the
> other
> change would be a step backwards.
>
> That is however just one specific case, and I needed to present what I
> believe is a more balanced view of that... but I will not focus on it
> in
> any further discussion.
> I do understand that your point is intended to be more general.
> In general, and *by definition*, the cases where you want Vector to be
> Array without adverse consequences are always cases where it can also
> *be*
> Array in the original as3 code. If the only justification for it being
> a
> Vector in as3 code is 'compile-time type safety', then the proposed
> alternative from Harbs and Josh is a better option because it retains
> the
> benefits you seek and is a better quality cross-target representation
> for
> this specific sort of requirement (it will also provide more benefits:
> most
> Vector methods do not have compile-time type safety because most their
> method signatures do not specify :T types, I hope the proposed
> alternative
> might address that).
> For the performance-oriented numeric types, which is another thing
> that has
> been raised, maybe Josh can somehow include that with the typed Arrays
> feature as he suggested, maybe not. If yes, then great, but if not, I
> am
> happy to explore other options for that.
>
> What I'd really like to hear are your thoughts about the concerns I
> raised
> for the:
> "new whateverclasstheconfigordirectivespecified()"
> approach to doing any of this.
>
> How do you propose to avoid risk to the community and potentially to
> Royale's reputation with release of swcs that can have different
> language-level variations in them (XML, Vector or anything that
> represents
> a core as3 'type')?
> Do we have to warn people not to do that, and then hope that they
> don't? A
> user of that swc doesn't see the emulation class that the swc may
> expose
> without investigating at runtime, they normally only see the type it
> represents, and unless they are warned, they have no reason to assume
> it
> won't do all the things it should. There could also be runtime conflict
> implications when mixing swcs with different emulation decisions, and
> that
> could even add weight overall compared to using one. None of this
> represents stuff that can't be figured out and addressed by developers
> who
> have to deal with it. But it seems to me to be something negative,
> which
> would be better to avoid.
>
> I think you are indicating the same desire to avoid this problem by
> saying
> that you want to specify things by 'the swc' you add (e.g. XML
> replacement)... but that can be too late, because even if an alternate
> emulation class itself is not bundled into a swc's code, all the calls
> to
> instantiate it are, which reflect its distinct package name and class
> name.
> I can envisage ways to achieve optimization and to avoid risks for the
> general case, but only if the instantiation calls for these language
> level
> emulations can never vary throughout the entire codebase (all swcs
> included), and the 'optimization' is therefore largely driven from the
> application build, and not dictated at swc level. Maybe swc libraries
> could
> be advertised as being compatible with some well-known optimizations in
> this case, it could even be a 'marketing' claim for the swc.
> The most appealing optimization solution (to me) would be one that
> takes
> more advantage of GCC (which I consider will be 'safer', and also least
> effort for the developer) when the application gets built, instead of
> actually changing the content of individual methods (for example) in
> 'lite'
> versions of replacement classes. However, I can see that doing the
> latter
> (or both) should also be possible and should not be much different, I
> think, from a regular monkey-patch approach, or from your desire for
> swc
> level replacement - but it only works if there is no variation in the
> actual naming of the classes that are being 'patched' (whether its via
> an
> alternate XML-like swc as a direct substitute for the standard one, or
> a
> local monkey patch). Maybe I'm missing something that is obvious to
> you...
> please tell me if I am.
>
>
> On Fri, May 31, 2019 at 6:37 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > It is pretty simple to me. The proposed Vector implementation is
> heavy
> > enough that we all agree that we don't want to use it for just one
> use case
> > in the Strand. And so we will stop using Vector and migrate to
> using a
> > plain Array. That agreement proves that the proposed changes are not
> > right. We will effectively encourage others to do the same.
> >
> > It would be much better if Royale had a way for developers to
> specify that
> > the one use of Vector in the Strand should be converted to plain
> Array by
> > the compiler and other uses could use the proposed Vector. That's
> how
> > optimization should be made available for all kinds of code in
> Royale, not
> > just for Vector.
> >
> > The current Vector output in the develop branch is low cost and fully
> > functional for some uses cases. As long as that output is still
> available
> > as a compiler option then having other output fine.
> >
> > I still haven't found time to look at the actual proposed changes,
> but I
> > would strongly prefer that, instead of having to modify compiler
> output
> > each time someone proposes a different Vector implementation, that
> the
> > changes can all be done by which SWC you choose for your Vector
> > implementation. There are other places in the compiler where you can
> > choose the class to use for Binding or ClassFactory. Hopefully the
> same
> > approach is being used for Vector. Ideally, the compile would just
> output
> > "new whateverclasstheconfigordirectivespecified()" and then just
> output the
> > usual push/pop/index calls and so it could just be plain Array where
> > specified or the proposed Vector and some other Vector someday.
> >
> > This is a case were "there is no one right way". And when we have
> those
> > situations, we must offer choices.
> >
> > -Alex
> >
> > On 5/30/19, 1:34 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > Hi,
> >
> > @Alex Harui <ah...@adobe.com> I think you misunderstood me.
> I'm not
> > saying
> > we should "remove choices". What I say is that we have finally a
> more
> > robust implementation and we can evolve to have more choices
> from that
> > point. I think continue from that safe point will give us many
> > benefits. So
> > I want those choices. What I don't want is to wait to make it
> perfect
> > to
> > merge. As I said before perfection is enemy of the progress.
> >
> > An important point I can't agree with you: Why we don't use
> Vector in
> > our
> > production App? Cause we can't. To do that we need: a) Greg
> changes
> > merged,
> > b) make AMF understand Vectors (still to be done to make Vector
> usable
> > for
> > us). Without both points Vectors are not an option for us. So I
> think
> > the
> > premise of "we have 2 apps in production without Vectors" are not
> > right. We
> > don't have still Jewel DataGrid, or Swiz Global Dispatcher, and
> that
> > does
> > not mean it's ok for us. Is just we still don't have it, but
> making us
> > to
> > make our product without all of that is a serious issue that we
> need to
> > workaround in some way. But we can do that as something
> "temporal",
> > due to
> > current Royale limitations. But our goal is to have all that,
> > Vector-AMF
> > included :)
> >
> > For this reason, I prefer to have Greg's Vector now, since it
> makes our
> > production App be one step closer to remove current workarounds
> :)
> > And I'm sure that not having a Vector solution like this, could
> be a
> > reason
> > why some people still didn't try Royale to migrate to this date.
> > So if you ask me or those people for a "priority path", we will
> say
> > "let's
> > get Vector first, then evolve from that to have more choices".
> > That's what I'm saying it's ok to merge now.
> >
> > I'm ok with having Vector as we all know it from AS3 (since is
> > that...AS3
> > Vector, don't forget that, and is what people expect to have at
> first
> > sight, then we can give them more choices and they will
> appreciate for
> > sure), and have as well a new Typed Array too as other proposed
> too.
> > That
> > will be for me options. But we should not wait to make all that
> happen
> > to
> > merge current branch, right?, All that we'll be lots of time to
> make it
> > perfect from day 0.
> >
> > The key concept for me was what Harbs said in his response to
> the end.
> > If
> > you don't use it the impact is 0, not 2-3k, since people don't
> have
> > Vector
> > presence in their codes. So that's PAYG. For that reason it's ok
> for
> > me to
> > merge and continue from that safe point, since we really only get
> > positive
> > things and nothing negative, and since we all agree in the same
> terms,
> > just
> > we need more time to continue evolving it to get to that perfect
> final
> > point.
> >
> >
> >
> >
> > El jue., 30 may. 2019 a las 7:56, Greg Dove (<
> greg.dove@gmail.com>)
> > escribió:
> >
> > > Harbs some quick comments inline...
> > >
> > > On Thu, May 30, 2019 at 4:27 PM Harbs <ha...@gmail.com>
> wrote:
> > >
> > > > The only niggle I have with my approach is that Vector in
> Flash is
> > more
> > > > performant than array, while in JS, it’s going to be the
> other way
> > > around.
> > > > So if someone has a performance-sensitive piece of code, how
> > should they
> > > > write it so it outputs as performant as possible on both
> platforms?
> > > >
> > > > Vector in flash is only substantially faster for its 3
> numeric
> > types
> > > which
> > > are optimized. It is (slightly) slower than Array in other
> cases - I
> > think
> > > it is normal that the extra type checking takes time even in
> native
> > code.
> > > I remember seeing some data which said it was 30% slower for
> some
> > methods
> > > with the non-primitive types, but that may be old.
> > >
> > > In terms of the emulation version, you can get javascript Array
> > speed with
> > > the index access and assignment, which should be a direct copy
> of
> > the same
> > > parts of code that are heavily optimized in flash I think.
> > >
> > > I was running performance tests on the non-debug flash player
> > alongside
> > > javascript. I actually see the regular native javascript Array
> > beating
> > > flash numeric Vectors in Chrome on windows, for the same tasks.
> > Perhaps the
> > > pepper plugin is getting less cpu resource than the browser or
> > something
> > > like that, not sure. I had assumed TypedArrays would be
> faster, but
> > > recently you said you weren't sure because of js engine
> smarts. I
> > will
> > > still check that.
> > >
> > >
> > >
> > > > I have not spent the time looking into the implementation,
> but I
> > think
> > > > there might be some cross-communication. My understanding
> from
> > what Greg
> > > > wrote is that if Vector is not used in an application, there
> will
> > be no
> > > > extra code due to dead code removal. If that’s correct, I
> think
> > we’re in
> > > > agreement that the implementation is fine. Do I understand
> > correctly?
> > > >
> > >
> > > That is correct.
> > >
> > >
> > > >
> > > > Harbs
> > > >
> > > > > On May 30, 2019, at 1:26 AM, Josh Tynjala <
> > joshtynjala@apache.org>
> > > > wrote:
> > > > >
> > > > > I definitely want the default choice to have as few
> surprises as
> > > > possible when it comes to how ActionScript behaves in Royale.
> > We'll never
> > > > have a perfect emulation, of course, but there are things
> that I
> > think
> > > can
> > > > still be improved. At the same time, I think it's perfectly
> valid
> > for
> > > > someone to want to opt into a typed Array that doesn't have
> the
> > runtime
> > > > overhead of Vector and isn't as heavy in file size. I'm wary
> of the
> > > > solution being a custom implementation of Vector with missing
> > features,
> > > > though. It will lead to confusion, even if it's opt-in.
> > > > >
> > > > > What Harbs suggested seems like a smart way to go. Rather
> than
> > having a
> > > > separate Vector implementation that doesn't work as
> developers are
> > used
> > > to,
> > > > a new variation of Array that has compile-time type checks
> but no
> > runtime
> > > > checks sounds like a more elegant solution. Like Vector
> works in
> > Royale
> > > > today, it can compile down to a regular JS Array, but at
> > compile-time,
> > > we'd
> > > > have some extra safety and could even possibly cast back and
> forth
> > with
> > > > untyped Arrays (which we can't do with Vector).
> > > > >
> > > > > - Josh
> > > > >
> > > > > On 2019/05/29 18:07:31, Alex Harui
> <ah...@adobe.com.INVALID>
> > wrote:
> > > > >> We must not eliminate choices.
> > > > >>
> > > > >> I still haven't had time to look at the branch.
> > > > >>
> > > > >> There must be away to avoid even a 1K cost to those who
> don't
> > need it.
> > > > >>
> > > > >> If there is such a way, then it is fine to merge.
> Otherwise,
> > everyone
> > > > is going to pay 2K to use a Vector when we know at least two
> apps
> > are in
> > > > production without needing that 2k.
> > > > >>
> > > > >> There are too many words being written and no technical
> points
> > being
> > > > made. I will try to resummarize.
> > > > >>
> > > > >> 1) It does not matter how fast your network is. Every
> other
> > app will
> > > > use more bandwidth and when the network gets busy or
> connectivity
> > gets
> > > poor
> > > > (something I see quite frequently where I live) either you
> get
> > your app
> > > to
> > > > run or you run out of time.
> > > > >>
> > > > >> 2) If you are not using some feature of our code, you
> should
> > not have
> > > > to pay for it in download cost. That's PAYG. That would be
> true
> > for
> > > > Vector, XML and even if we had to write a Date
> implementation. It
> > is not
> > > > an issue of non-conforming. It is an issue of
> optimization. If
> > you
> > > aren't
> > > > going to use some feature of E4x you should have the option
> of
> > using code
> > > > that doesn't have those code paths. Same for if we had to
> do Date.
> > > > >>
> > > > >> We know that if you don't need runtime-type checking and
> > fixed-length
> > > > checking that a plain Array is just fine and 2K cheaper.
> Let's
> > give
> > > folks
> > > > the option to do that.
> > > > >>
> > > > >> I will repeat that I do not have any objection to having
> a full
> > Vector
> > > > implementation with runtime type-checking and fixed length
> > checking be
> > > the
> > > > default choice as long as folks can optimize back to using
> the
> > plain
> > > Array
> > > > code we use now.
> > > > >>
> > > > >> For the one Vector we currently have in all apps for the
> > Strand, it
> > > > might be time to change that to an array and check the type
> (in
> > > debug-only
> > > > code) on addBead. Either that or we add compiler options so
> that
> > one
> > > > Vector gets optimized to the current plain Array code.
> > > > >>
> > > > >> It is not a technical argument to classify Vector as
> "Language"
> > and
> > > > therefore somehow an exception to being optimizable.
> > > > >>
> > > > >> My 2 cents,
> > > > >> -Alex
> > > > >>
> > > > >>
> > > > >> On 5/28/19, 2:59 AM, "Carlos Rovira" <
> carlosrovira@apache.org>
> > > wrote:
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I think that we all agree in most of the things, and
> > although we're
> > > > >> discussing some particularities on how to solve, my
> opinion
> > is that
> > > > those
> > > > >> particularities can be solved after merging Language
> > improvements
> > > > branch.
> > > > >> We all agree we need this Vector (and other
> improvements in
> > this
> > > > branch)?.
> > > > >> So, after that merge folks wanting to improve, let's
> say,
> > > Vector(for
> > > > >> example) even more with new choices can do that without
> > problem and
> > > > will
> > > > >> make it even better.
> > > > >>
> > > > >> Are we ok with that?
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> El mar., 28 may. 2019 a las 11:07, Harbs (<
> > harbs.lists@gmail.com>)
> > > > escribió:
> > > > >>
> > > > >>>
> > > > >>>> On May 28, 2019, at 11:12 AM, Greg Dove <
> greg.dove@gmail.com>
> > > wrote:
> > > > >>>>
> > > > >>>>> "I personally have never used length checking in
> Vector. Nor
> > was
> > > > runtime
> > > > >>>>> type checking on Vectors important to me. "
> > > > >>>> length checking is automatic in flash. I don't know
> that you
> > 'use'
> > > > it...
> > > > >>> it
> > > > >>>> is just there.
> > > > >>>
> > > > >>> True. What I meant is that I never used fixed length
> Vectors.
> > > > >>>
> > > > >>>> In javascript I expect it would most often be switched
> off in
> > all
> > > > release
> > > > >>>> builds, but having it on by default provides another
> check of
> > > > something
> > > > >>>> that could provide a vital clue to help people figuring
> out
> > problems
> > > > in
> > > > >>>> code.
> > > > >>>> So far each 'stronger typing' feature added in the last
> few
> > months
> > > has
> > > > >>>> revealed potential issues or - most often - bad code
> that was
> > > working
> > > > >>> when
> > > > >>>> it should not
> > > > >>>
> > > > >>> Good points, and one that argues for the ability to have
> these
> > checks
> > > > >>> while debugging and have the run-time code removed on
> release.
> > > > >>>
> > > > >>>> One thing about the mxml stuff is that it gets
> processed in a
> > way
> > > > that is
> > > > >>>> untyped.
> > > > >>>
> > > > >>>
> > > > >>> Agree. I do wish there was some way for MXML to be output
> > “better”
> > > > where
> > > > >>> minified vars could “just work” and types could be better
> > inferred
> > > > from the
> > > > >>> MXML files.
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Carlos Rovira
> > > > >>
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7b5824f745304f9e222308d6e57cfac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948722282899722&sdata=T5XYilhl3fSjVqu60ZolwQWXIczCR5w73axIKMd%2BDS0%3D&reserved=0
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7b5824f745304f9e222308d6e57cfac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948722282899722&sdata=T5XYilhl3fSjVqu60ZolwQWXIczCR5w73axIKMd%2BDS0%3D&reserved=0
> >
> >
> >
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
Hi Alex, it seems I do need to make one more post after all.
I do feel like I have shared all this information before, but I will make
'one more entry' in case I did not do that with clarity:
On Wed, Jun 5, 2019 at 6:36 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> Your summary of my opinion is not correct.
>
> If Vector-as-array is what the current develop branch output is, I am
> unable to understand how that output is incorrect or poses any risks for
> anyone who knows they will not need runtime type-checking or runtime
> fixed-length checking. And thus, it should remain an option. For sure, it
> was good enough for at least two production apps.
>
> I said previously that I don't consider that single case to be a
validation for a more general case, it is just using index access and one
push, iirc. And it really offers no value for runtime safety in the swf
version because the runtime safety for the push call was already guarded by
the signature of the enclosing method. It has already been addressed in the
branch in ways we already discussed at length.
I'd guess that Harbs' experience might validate Vector-as-Array more,
because it sounds like he was using Vector (and therefore Vector-as-Array)
much more than that, iiuc, but Harbs also seemed willing to consider other
options.
While I personally don't think that example justifies it as a feature, I'm
not interested in using it as any justification to oppose it. Like I said,
I will add it back.
I consider that specific example (as it is currently in develop) 'safe' in
the swc *because* it abides by the following:
'Don't use any emulation classes in library code unless your emulation
class is Array, and if it is Array, don't expose the Vector type on any
public or protected api surface because it will be a misleading
representation of the type to the user of that api'
The Vector instance being substituted with Array is a private instance and
is never exposed via public or protected access, so it is 'safe'
If someone (anyone), at some point, released the same swc after adding
public function getMyBeadVector():Vector.IBead {
return _beads; //share the private instance
}
I consider it not to be 'safe'.
(I'm not using angle brackets above because they mess up some readers it
seems)
At that point it gives someone else a potential problem, because it is
really returning an Array, instead of a distinctive Vector type, and can
only be 'safe-ish' if the user of the swc (it might be another library or
application) knows its limitations or happens to be applying the same
optimization to their own code (and accepting whatever risks they do with
that). It may not be obvious to the user of the swc that the instance is an
Array because their IDE tells them it is a Vector, but it can behave
differently to how they expect a Vector to behave. They might end up adding
code to offset the unusual behaviour, or doing things which break things
later if a more conformant Vector is swapped in. Using Array here is just a
specific example of the more general emulation class like approach, so
similar concerns apply to using other emulation classes.
Anyway, we can set that specific example of IBead aside. Like I said it is
'safe' as it is.
For the other points, most of them have been discussed already. The sky's
the limit for what options we could provide. But providing lots of options
is not itself without cost.
I already mentioned I'd rather add things for Vector optimization based on
feedback for what people need than try to guess what those things are or
assume that what I think is what they want.
For the Vector case in general, I think of it in two different ways
1. People trying to port existing as3 codebases.
Usually the goal is to get things working first and then optimize/customize
as necessary. At least that is the approach I am familiar with.
The first part of that is what I have been focused on with Vector - code
that 'just works' as-is when ported. The second part could be achieved by
using Vector configuration/tuning options. Or it could be by refactoring
portions of the original code to reflect best practice for specific
targets, or it could be by substituting new options (Harbs' and Josh'
suggestions) which reflect improved cross-target features for compile-time
only safety.
2. People writing new as3 code from scratch for royale
If 'compile-time' safety is the main goal, then what Harbs and Josh
suggested is the thing I personally would use most instead of Vector here.
That is what the (proposed) feature represents as being more
fit-for-purpose than Vector which has limited compile-time type safety
anyway. That could probably even support 'opt-in' runtime-safety checks for
things like push and unshift etc (instead of 'opt-out' from Vector, for
example), or maybe it could leverage the complex-implicit-coercions feature
in the branch which is more general, and can also be switched off globally
or toggled locally.
if 'run-time' safety is the main goal, they can choose Vector, with or
without performance tweaks.
or they can simply use Array. And add some debug only runtime safety for
example, just like we already discussed for IBead.
For numeric typed array performance, we also need a way to aim for best
cross target results, we already discussed that in the thread too. Maybe
that could be via improvements to the Vector implementation, maybe via what
Josh suggested, maybe some specific new classes. That is part of next steps.
Adding more and more configuration options might sound like a good idea,
but it could also mean we are spending lots of time on things people don't
care about.
I added the most obvious one for Vector in the branch, but held back on
doing more 'optimization options' for now, as I mentioned previously. But,
again, as I said earlier, I am happy to improve it with more options for
tuning it if there is demonstrable need. There are some minimal things that
I believe really would not make sense though, such as returning something
that is a regular Array instead of something that is recognizable as a
Vector type from concat, or slice methods, for example.
"We do not need to reach a collaborative decision that is A or B. Why
should we think we know what our users really need? We provide
options/choices so the users can decide for themselves. And invite someone
else to come up with even a better solution or solutions."
Agreed. But it might be better to get feedback on what people want instead
of unleashing an endless menu for those options/choices. And I say that as
someone who 'likes' lots of options and freedom to do things myself.
However offering a vast array of options can be confusing to people who are
unfamiliar with them, so we should at least consider that too. Building
that menu more based on feedback after 1.0 release is one approach to
consider in order to offer the options most aligned with the needs of the
community. It might even be a good way to draw more people into getting
involved in Royale. But I don't have any magic solution for us figuring out
where the threshold is for any particular thing, and I know we still need
to present our 'best guess' range of options at 1.0. Yours includes
Vector-as-Array and the emulation class approach. I accept that. If the
above example makes my concerns more clear to you now, maybe you can
re-read the latter part of my last message and see if that 'middle-ground'
part also makes more sense in context.
The only other thing I'd like to be really clear about is that I have no
emotional attachment to the Vector implementation in the branch. After I
merge you or others are free to improve it or completely replace it. The
only thing that would concern me is if all the unit tests that drove its
development did not continue to pass after any changes. I will port these
tests to Josh's setup in RoyaleUnit as soon as I can. I am actually more
'attached' to the unit tests than to the implementation. Having these unit
tests should provide a useful roadmap for any new targets that will need
their own language emulation support to be developed in the future (after
the dependencies for running the unit tests themselves have been emulated
in that same target).
Anyway, I 'stopped' posting because I felt like I'd explained everything I
could in terms of what I felt was important. I broke that extremely short
'silence' here with only one goal: to communicate more clearly what it
seems I have not succeeded in doing before now.
I hope I did that and that you at least understand why I have a certain
view, irrespective of whether you share the same concerns I expressed or
not. Regardless, I don't think I can express anything about this more than
I already have.
I also have no certainty that others share my specific concerns. Perhaps I
am really missing something here and they are not even valid. So far I
don't think so, but if they are, I can only apologize for wasting
everybody's time.
And as I said, I will add the functionality for Array output back.
So this is the real 'last message' :)
(That's probably a relief to many people, but it is also a relief to me,
because like I said, I don't find this to be the most efficient way to
communicate, it is considerable effort. )
On Wed, Jun 5, 2019 at 6:36 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> Your summary of my opinion is not correct.
>
> If Vector-as-array is what the current develop branch output is, I am
> unable to understand how that output is incorrect or poses any risks for
> anyone who knows they will not need runtime type-checking or runtime
> fixed-length checking. And thus, it should remain an option. For sure, it
> was good enough for at least two production apps.
>
> If you are specifically referring to the use of Vector in the Strand, it
> occurred to me that someone could add another option to inject a type-check
> before every push on the Vector-as-Array. I think that would allow us to
> continue to use Vector in the Strand at a cost much less than 2K. And
> allow many others to get type-checking on push as well. Or, as we
> discussed earlier, we can just stop using Vector in the Strand.
>
> If you are saying that the risk and harm to the community will come when
> someone tries to add a bead to the strand at runtime that was instantiated
> in a way that was not testable at development time, then I guess we will
> have to agree to disagree on how important that is. IMO, that runtime
> checking should be PAYG, and I would much rather that we spend time
> devising a scheme to allow folks to opt-in to runtime checking than tell
> folks that they must carry around extra code just-in-case someone else
> needs runtime checking. It could be something as brute force as specifying
> files in a compiler option where the compiler will replace "goog.DEBUG"
> with "true". Specific to the strand, yet another option could just be a
> bead that watches for beadAdded events and checks for IBead. Could be we
> find a way to replace Vector-as-Array code in libraries with the Vector
> implementation you've written.
>
> Or maybe, we should spend more time getting the SWF versions of the
> framework running well enough to have RoyaleUnit or some test automation
> run your app in the Flash/AIR runtimes so lots more things get checked
> (missing interface members, other type-checks, etc).
>
> Regardless, it is still great that you've created a runtime-checking
> implementation of Vector for those who need it.
>
> We do not need to reach a collaborative decision that is A or B. Why
> should we think we know what our users really need? We provide
> options/choices so the users can decide for themselves. And invite someone
> else to come up with even a better solution or solutions.
>
> My 2 cents,
> -Alex
>
> On 6/3/19, 11:04 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Hi Alex, this will be my last message in this thread.
>
> "The whole point of giving choices is to avoid having to spend so many
> emails trying to reach a decision. "
> Alex, I really don't understand your stance. The focus of the recent
> discussion has been on the choices themselves... concerns about their
> potential risks, along with ideas for improvements and code quality.
> It sounds like you are saying that we can't talk about improving the
> choices we already had, because if they exist that is all that matters.
> As far as I understand, the point of these email discussions is to
> reach
> the best quality collaborative decisions.
> I don't enjoy the process myself. It's inefficient. But we have an
> obligation to be collaborative (I think?). Expressing something along
> the
> lines of 'just do it and move on' does not seem to be that.
> I don't care about any of these things in terms of how it affects me
> personally, I have only pursued the topic in relation to what I think
> will
> help Royale be successful.
>
> The only way I can interpret your replies thus far is:
> More options for optimization are always better, even if they might
> present
> possible risks that could harm the community. We deal with those risks
> by
> issuing warnings.
> Specifically, in this case, a library developer being able to dictate
> certain optimization(s) that should be used by (and any associated
> risks
> that should be accepted by) the application developer is not
> unacceptable.
>
> -Your approach to mitigation of the above risks will be for us to warn
> people not to do the specific things that could cause the problems in
> the
> first place (from your comment about tools, risks, and documentation).
> Something like:
> 'Don't use any emulation classes in library code unless your emulation
> class is Array, and if it is Array, don't expose the Vector type on any
> public or protected api surface because it will be a misleading
> representation of the type to the user of that api'
>
> Is that a fair summary?
>
> It should be not surprise to you that I personally think the above is
> confusing and avoidable, because I consider that there are (and will
> be)
> better options that achieve the same optimization results. But I
> understand
> that you don't, and I can accept that. So I will make one last attempt
> to
> find something that I think is middle ground...
>
> Vector-as-Array is just a special case of the emulationClass approach.
> The only middle ground I can think of with regard to reducing the risk
> is
> to have the 'emulationClass' approach is to actually re-map the type
> in the
> javascript output, so the swc typing actually represents the type it
> has
> been transformed to.
> This means if people don't follow the above instructions and the type
> is
> exposed on an api surface then it is not misrepresented to unsuspecting
> users via the swc that has the optimization. Does that make any sense?
> I have no idea at this point if this is easy to do or not. But it would
> address the main things that worry me about this (again, not for me,
> for
> royale in general). I only got to this idea out of frustration,
> although
> perhaps it could be considered obvious in retrospect.
> I'm not able to tackle this in the near term but I will be happy to
> pursue
> it at some point if you can agree it is a good compromise ( I hope it
> might
> be). As I said, I won't continue any more in this thread. If you like
> it
> please let me know, otherwise I officially give up.
>
> For now, I will try to find time to add the Vector-as-Array back in
> sometime later this week. I will do it inside the vectorEmulationClass
> code
> branches in the compiler as a special case of ' vectorEmulationClass '.
> Once I have that done and working I will merge.
>
>
> On Sat, Jun 1, 2019 at 8:26 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > Greg, you are still trying to use the language conformance
> argument. This
> > is not an issue of language conformance, it is an issue of
> optimization.
> > Code paths not needed should not be downloaded. Every app
> development tool
> > I've used that offers optimizations offers optimization levels and
> > documentation of risks.
> >
> > There is a disagreement on how to implement Vector in JS as well.
> The
> > whole point of giving choices is to avoid having to spend so many
> emails
> > trying to reach a decision. Just provide choices so we can move
> on. Every
> > argument you make below is an argument for giving choices.
> >
> > -Alex
> >
> > On 5/30/19, 9:03 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >
> > "And so we will stop using Vector and migrate to using a plain
> Array.
> > That
> > agreement proves that the proposed changes are not right." We
> will
> > effectively encourage others to do the same.
> >
> > It does not prove that at all, Alex. It depends on the criteria,
> and we
> > have no commonly accepted guiding principles for what is 'right'
> here.
> > At least one of us believes that it is more correct that (in the
> > absence of
> > other proposed options) it be an Array in the original code.
> > If you take a step back and look at it from a broader
> perspective, it
> > can
> > be equally true to say 'This agreement proves that the original
> > implementation was not right'.
> > Firstly, I don't think Vector type was providing any benefit in
> this
> > case
> > in the first place (but that alone is not a reason to change it,
> > awareness
> > that it 'costs more' would however be a valid reason if there
> are no
> > benefits to using it).
> > Secondly, the collaborative outcome resulting in the use of
> explicit
> > Array
> > and the goog.DEBUG check is better than the original
> Vector-as-Array
> > output
> > because it offers the runtime type safety that was missing
> because it
> > was
> > not behaving like a Vector - and it retains the advantage of
> > zero-weight in
> > release build. Making these changes *is* a form of optimization
> based
> > on
> > using options currently available, it just happens to be
> hand-coded
> > and not
> > compiler-generated.
> > I know it's at least a little bit useful in its new form,
> because prior
> > testing with the branch level Vector implementation flagged a
> > non-conforming IBead in the 2nd app I tested it with, something
> that
> > was
> > not found by the original 'Array' implementation.
> > SWF testing in parallel would have caught that too, but is not a
> > realistic
> > assumption to have that as part of the workflow for checking
> runtime
> > behavior anymore, so this 'Array with debug-only typecheck' in
> > javascript
> > is a good outcome.
> > In this case, going back to Vector-as-Array output without
> making the
> > other
> > change would be a step backwards.
> >
> > That is however just one specific case, and I needed to present
> what I
> > believe is a more balanced view of that... but I will not focus
> on it
> > in
> > any further discussion.
> > I do understand that your point is intended to be more general.
> > In general, and *by definition*, the cases where you want Vector
> to be
> > Array without adverse consequences are always cases where it can
> also
> > *be*
> > Array in the original as3 code. If the only justification for it
> being
> > a
> > Vector in as3 code is 'compile-time type safety', then the
> proposed
> > alternative from Harbs and Josh is a better option because it
> retains
> > the
> > benefits you seek and is a better quality cross-target
> representation
> > for
> > this specific sort of requirement (it will also provide more
> benefits:
> > most
> > Vector methods do not have compile-time type safety because most
> their
> > method signatures do not specify :T types, I hope the proposed
> > alternative
> > might address that).
> > For the performance-oriented numeric types, which is another
> thing
> > that has
> > been raised, maybe Josh can somehow include that with the typed
> Arrays
> > feature as he suggested, maybe not. If yes, then great, but if
> not, I
> > am
> > happy to explore other options for that.
> >
> > What I'd really like to hear are your thoughts about the
> concerns I
> > raised
> > for the:
> > "new whateverclasstheconfigordirectivespecified()"
> > approach to doing any of this.
> >
> > How do you propose to avoid risk to the community and
> potentially to
> > Royale's reputation with release of swcs that can have different
> > language-level variations in them (XML, Vector or anything that
> > represents
> > a core as3 'type')?
> > Do we have to warn people not to do that, and then hope that they
> > don't? A
> > user of that swc doesn't see the emulation class that the swc may
> > expose
> > without investigating at runtime, they normally only see the
> type it
> > represents, and unless they are warned, they have no reason to
> assume
> > it
> > won't do all the things it should. There could also be runtime
> conflict
> > implications when mixing swcs with different emulation
> decisions, and
> > that
> > could even add weight overall compared to using one. None of this
> > represents stuff that can't be figured out and addressed by
> developers
> > who
> > have to deal with it. But it seems to me to be something
> negative,
> > which
> > would be better to avoid.
> >
> > I think you are indicating the same desire to avoid this problem
> by
> > saying
> > that you want to specify things by 'the swc' you add (e.g. XML
> > replacement)... but that can be too late, because even if an
> alternate
> > emulation class itself is not bundled into a swc's code, all the
> calls
> > to
> > instantiate it are, which reflect its distinct package name and
> class
> > name.
> > I can envisage ways to achieve optimization and to avoid risks
> for the
> > general case, but only if the instantiation calls for these
> language
> > level
> > emulations can never vary throughout the entire codebase (all
> swcs
> > included), and the 'optimization' is therefore largely driven
> from the
> > application build, and not dictated at swc level. Maybe swc
> libraries
> > could
> > be advertised as being compatible with some well-known
> optimizations in
> > this case, it could even be a 'marketing' claim for the swc.
> > The most appealing optimization solution (to me) would be one
> that
> > takes
> > more advantage of GCC (which I consider will be 'safer', and
> also least
> > effort for the developer) when the application gets built,
> instead of
> > actually changing the content of individual methods (for
> example) in
> > 'lite'
> > versions of replacement classes. However, I can see that doing
> the
> > latter
> > (or both) should also be possible and should not be much
> different, I
> > think, from a regular monkey-patch approach, or from your desire
> for
> > swc
> > level replacement - but it only works if there is no variation
> in the
> > actual naming of the classes that are being 'patched' (whether
> its via
> > an
> > alternate XML-like swc as a direct substitute for the standard
> one, or
> > a
> > local monkey patch). Maybe I'm missing something that is obvious
> to
> > you...
> > please tell me if I am.
> >
> >
> > On Fri, May 31, 2019 at 6:37 AM Alex Harui
> <ah...@adobe.com.invalid>
> > wrote:
> >
> > > It is pretty simple to me. The proposed Vector implementation
> is
> > heavy
> > > enough that we all agree that we don't want to use it for just
> one
> > use case
> > > in the Strand. And so we will stop using Vector and migrate to
> > using a
> > > plain Array. That agreement proves that the proposed changes
> are not
> > > right. We will effectively encourage others to do the same.
> > >
> > > It would be much better if Royale had a way for developers to
> > specify that
> > > the one use of Vector in the Strand should be converted to
> plain
> > Array by
> > > the compiler and other uses could use the proposed Vector.
> That's
> > how
> > > optimization should be made available for all kinds of code in
> > Royale, not
> > > just for Vector.
> > >
> > > The current Vector output in the develop branch is low cost
> and fully
> > > functional for some uses cases. As long as that output is
> still
> > available
> > > as a compiler option then having other output fine.
> > >
> > > I still haven't found time to look at the actual proposed
> changes,
> > but I
> > > would strongly prefer that, instead of having to modify
> compiler
> > output
> > > each time someone proposes a different Vector implementation,
> that
> > the
> > > changes can all be done by which SWC you choose for your Vector
> > > implementation. There are other places in the compiler where
> you can
> > > choose the class to use for Binding or ClassFactory.
> Hopefully the
> > same
> > > approach is being used for Vector. Ideally, the compile would
> just
> > output
> > > "new whateverclasstheconfigordirectivespecified()" and then
> just
> > output the
> > > usual push/pop/index calls and so it could just be plain Array
> where
> > > specified or the proposed Vector and some other Vector someday.
> > >
> > > This is a case were "there is no one right way". And when we
> have
> > those
> > > situations, we must offer choices.
> > >
> > > -Alex
> > >
> > > On 5/30/19, 1:34 AM, "Carlos Rovira" <ca...@apache.org>
> > wrote:
> > >
> > > Hi,
> > >
> > > @Alex Harui <ah...@adobe.com> I think you misunderstood
> me.
> > I'm not
> > > saying
> > > we should "remove choices". What I say is that we have
> finally a
> > more
> > > robust implementation and we can evolve to have more
> choices
> > from that
> > > point. I think continue from that safe point will give us
> many
> > > benefits. So
> > > I want those choices. What I don't want is to wait to make
> it
> > perfect
> > > to
> > > merge. As I said before perfection is enemy of the
> progress.
> > >
> > > An important point I can't agree with you: Why we don't use
> > Vector in
> > > our
> > > production App? Cause we can't. To do that we need: a) Greg
> > changes
> > > merged,
> > > b) make AMF understand Vectors (still to be done to make
> Vector
> > usable
> > > for
> > > us). Without both points Vectors are not an option for us.
> So I
> > think
> > > the
> > > premise of "we have 2 apps in production without Vectors"
> are not
> > > right. We
> > > don't have still Jewel DataGrid, or Swiz Global
> Dispatcher, and
> > that
> > > does
> > > not mean it's ok for us. Is just we still don't have it,
> but
> > making us
> > > to
> > > make our product without all of that is a serious issue
> that we
> > need to
> > > workaround in some way. But we can do that as something
> > "temporal",
> > > due to
> > > current Royale limitations. But our goal is to have all
> that,
> > > Vector-AMF
> > > included :)
> > >
> > > For this reason, I prefer to have Greg's Vector now, since
> it
> > makes our
> > > production App be one step closer to remove current
> workarounds
> > :)
> > > And I'm sure that not having a Vector solution like this,
> could
> > be a
> > > reason
> > > why some people still didn't try Royale to migrate to this
> date.
> > > So if you ask me or those people for a "priority path", we
> will
> > say
> > > "let's
> > > get Vector first, then evolve from that to have more
> choices".
> > > That's what I'm saying it's ok to merge now.
> > >
> > > I'm ok with having Vector as we all know it from AS3
> (since is
> > > that...AS3
> > > Vector, don't forget that, and is what people expect to
> have at
> > first
> > > sight, then we can give them more choices and they will
> > appreciate for
> > > sure), and have as well a new Typed Array too as other
> proposed
> > too.
> > > That
> > > will be for me options. But we should not wait to make all
> that
> > happen
> > > to
> > > merge current branch, right?, All that we'll be lots of
> time to
> > make it
> > > perfect from day 0.
> > >
> > > The key concept for me was what Harbs said in his response
> to
> > the end.
> > > If
> > > you don't use it the impact is 0, not 2-3k, since people
> don't
> > have
> > > Vector
> > > presence in their codes. So that's PAYG. For that reason
> it's ok
> > for
> > > me to
> > > merge and continue from that safe point, since we really
> only get
> > > positive
> > > things and nothing negative, and since we all agree in the
> same
> > terms,
> > > just
> > > we need more time to continue evolving it to get to that
> perfect
> > final
> > > point.
> > >
> > >
> > >
> > >
> > > El jue., 30 may. 2019 a las 7:56, Greg Dove (<
> > greg.dove@gmail.com>)
> > > escribió:
> > >
> > > > Harbs some quick comments inline...
> > > >
> > > > On Thu, May 30, 2019 at 4:27 PM Harbs <
> harbs.lists@gmail.com>
> > wrote:
> > > >
> > > > > The only niggle I have with my approach is that Vector
> in
> > Flash is
> > > more
> > > > > performant than array, while in JS, it’s going to be
> the
> > other way
> > > > around.
> > > > > So if someone has a performance-sensitive piece of
> code, how
> > > should they
> > > > > write it so it outputs as performant as possible on
> both
> > platforms?
> > > > >
> > > > > Vector in flash is only substantially faster for its 3
> > numeric
> > > types
> > > > which
> > > > are optimized. It is (slightly) slower than Array in
> other
> > cases - I
> > > think
> > > > it is normal that the extra type checking takes time
> even in
> > native
> > > code.
> > > > I remember seeing some data which said it was 30% slower
> for
> > some
> > > methods
> > > > with the non-primitive types, but that may be old.
> > > >
> > > > In terms of the emulation version, you can get
> javascript Array
> > > speed with
> > > > the index access and assignment, which should be a
> direct copy
> > of
> > > the same
> > > > parts of code that are heavily optimized in flash I
> think.
> > > >
> > > > I was running performance tests on the non-debug flash
> player
> > > alongside
> > > > javascript. I actually see the regular native javascript
> Array
> > > beating
> > > > flash numeric Vectors in Chrome on windows, for the same
> tasks.
> > > Perhaps the
> > > > pepper plugin is getting less cpu resource than the
> browser or
> > > something
> > > > like that, not sure. I had assumed TypedArrays would be
> > faster, but
> > > > recently you said you weren't sure because of js engine
> > smarts. I
> > > will
> > > > still check that.
> > > >
> > > >
> > > >
> > > > > I have not spent the time looking into the
> implementation,
> > but I
> > > think
> > > > > there might be some cross-communication. My
> understanding
> > from
> > > what Greg
> > > > > wrote is that if Vector is not used in an application,
> there
> > will
> > > be no
> > > > > extra code due to dead code removal. If that’s
> correct, I
> > think
> > > we’re in
> > > > > agreement that the implementation is fine. Do I
> understand
> > > correctly?
> > > > >
> > > >
> > > > That is correct.
> > > >
> > > >
> > > > >
> > > > > Harbs
> > > > >
> > > > > > On May 30, 2019, at 1:26 AM, Josh Tynjala <
> > > joshtynjala@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > I definitely want the default choice to have as few
> > surprises as
> > > > > possible when it comes to how ActionScript behaves in
> Royale.
> > > We'll never
> > > > > have a perfect emulation, of course, but there are
> things
> > that I
> > > think
> > > > can
> > > > > still be improved. At the same time, I think it's
> perfectly
> > valid
> > > for
> > > > > someone to want to opt into a typed Array that doesn't
> have
> > the
> > > runtime
> > > > > overhead of Vector and isn't as heavy in file size.
> I'm wary
> > of the
> > > > > solution being a custom implementation of Vector with
> missing
> > > features,
> > > > > though. It will lead to confusion, even if it's opt-in.
> > > > > >
> > > > > > What Harbs suggested seems like a smart way to go.
> Rather
> > than
> > > having a
> > > > > separate Vector implementation that doesn't work as
> > developers are
> > > used
> > > > to,
> > > > > a new variation of Array that has compile-time type
> checks
> > but no
> > > runtime
> > > > > checks sounds like a more elegant solution. Like Vector
> > works in
> > > Royale
> > > > > today, it can compile down to a regular JS Array, but
> at
> > > compile-time,
> > > > we'd
> > > > > have some extra safety and could even possibly cast
> back and
> > forth
> > > with
> > > > > untyped Arrays (which we can't do with Vector).
> > > > > >
> > > > > > - Josh
> > > > > >
> > > > > > On 2019/05/29 18:07:31, Alex Harui
> > <ah...@adobe.com.INVALID>
> > > wrote:
> > > > > >> We must not eliminate choices.
> > > > > >>
> > > > > >> I still haven't had time to look at the branch.
> > > > > >>
> > > > > >> There must be away to avoid even a 1K cost to those
> who
> > don't
> > > need it.
> > > > > >>
> > > > > >> If there is such a way, then it is fine to merge.
> > Otherwise,
> > > everyone
> > > > > is going to pay 2K to use a Vector when we know at
> least two
> > apps
> > > are in
> > > > > production without needing that 2k.
> > > > > >>
> > > > > >> There are too many words being written and no
> technical
> > points
> > > being
> > > > > made. I will try to resummarize.
> > > > > >>
> > > > > >> 1) It does not matter how fast your network is.
> Every
> > other
> > > app will
> > > > > use more bandwidth and when the network gets busy or
> > connectivity
> > > gets
> > > > poor
> > > > > (something I see quite frequently where I live) either
> you
> > get
> > > your app
> > > > to
> > > > > run or you run out of time.
> > > > > >>
> > > > > >> 2) If you are not using some feature of our code,
> you
> > should
> > > not have
> > > > > to pay for it in download cost. That's PAYG. That
> would be
> > true
> > > for
> > > > > Vector, XML and even if we had to write a Date
> > implementation. It
> > > is not
> > > > > an issue of non-conforming. It is an issue of
> > optimization. If
> > > you
> > > > aren't
> > > > > going to use some feature of E4x you should have the
> option
> > of
> > > using code
> > > > > that doesn't have those code paths. Same for if we
> had to
> > do Date.
> > > > > >>
> > > > > >> We know that if you don't need runtime-type
> checking and
> > > fixed-length
> > > > > checking that a plain Array is just fine and 2K
> cheaper.
> > Let's
> > > give
> > > > folks
> > > > > the option to do that.
> > > > > >>
> > > > > >> I will repeat that I do not have any objection to
> having
> > a full
> > > Vector
> > > > > implementation with runtime type-checking and fixed
> length
> > > checking be
> > > > the
> > > > > default choice as long as folks can optimize back to
> using
> > the
> > > plain
> > > > Array
> > > > > code we use now.
> > > > > >>
> > > > > >> For the one Vector we currently have in all apps
> for the
> > > Strand, it
> > > > > might be time to change that to an array and check the
> type
> > (in
> > > > debug-only
> > > > > code) on addBead. Either that or we add compiler
> options so
> > that
> > > one
> > > > > Vector gets optimized to the current plain Array code.
> > > > > >>
> > > > > >> It is not a technical argument to classify Vector as
> > "Language"
> > > and
> > > > > therefore somehow an exception to being optimizable.
> > > > > >>
> > > > > >> My 2 cents,
> > > > > >> -Alex
> > > > > >>
> > > > > >>
> > > > > >> On 5/28/19, 2:59 AM, "Carlos Rovira" <
> > carlosrovira@apache.org>
> > > > wrote:
> > > > > >>
> > > > > >> Hi,
> > > > > >>
> > > > > >> I think that we all agree in most of the things,
> and
> > > although we're
> > > > > >> discussing some particularities on how to solve,
> my
> > opinion
> > > is that
> > > > > those
> > > > > >> particularities can be solved after merging
> Language
> > > improvements
> > > > > branch.
> > > > > >> We all agree we need this Vector (and other
> > improvements in
> > > this
> > > > > branch)?.
> > > > > >> So, after that merge folks wanting to improve,
> let's
> > say,
> > > > Vector(for
> > > > > >> example) even more with new choices can do that
> without
> > > problem and
> > > > > will
> > > > > >> make it even better.
> > > > > >>
> > > > > >> Are we ok with that?
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> El mar., 28 may. 2019 a las 11:07, Harbs (<
> > > harbs.lists@gmail.com>)
> > > > > escribió:
> > > > > >>
> > > > > >>>
> > > > > >>>> On May 28, 2019, at 11:12 AM, Greg Dove <
> > greg.dove@gmail.com>
> > > > wrote:
> > > > > >>>>
> > > > > >>>>> "I personally have never used length checking in
> > Vector. Nor
> > > was
> > > > > runtime
> > > > > >>>>> type checking on Vectors important to me. "
> > > > > >>>> length checking is automatic in flash. I don't
> know
> > that you
> > > 'use'
> > > > > it...
> > > > > >>> it
> > > > > >>>> is just there.
> > > > > >>>
> > > > > >>> True. What I meant is that I never used fixed
> length
> > Vectors.
> > > > > >>>
> > > > > >>>> In javascript I expect it would most often be
> switched
> > off in
> > > all
> > > > > release
> > > > > >>>> builds, but having it on by default provides
> another
> > check of
> > > > > something
> > > > > >>>> that could provide a vital clue to help people
> figuring
> > out
> > > problems
> > > > > in
> > > > > >>>> code.
> > > > > >>>> So far each 'stronger typing' feature added in
> the last
> > few
> > > months
> > > > has
> > > > > >>>> revealed potential issues or - most often - bad
> code
> > that was
> > > > working
> > > > > >>> when
> > > > > >>>> it should not
> > > > > >>>
> > > > > >>> Good points, and one that argues for the ability
> to have
> > these
> > > checks
> > > > > >>> while debugging and have the run-time code removed
> on
> > release.
> > > > > >>>
> > > > > >>>> One thing about the mxml stuff is that it gets
> > processed in a
> > > way
> > > > > that is
> > > > > >>>> untyped.
> > > > > >>>
> > > > > >>>
> > > > > >>> Agree. I do wish there was some way for MXML to be
> output
> > > “better”
> > > > > where
> > > > > >>> minified vars could “just work” and types could be
> better
> > > inferred
> > > > > from the
> > > > > >>> MXML files.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Carlos Rovira
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C5b7ab8201190466822d808d6e8b27112%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636952250440875188&sdata=5GD9W1AzFE837vinQ1oVWZr7%2FRRad1YqY9DpIkSVYIk%3D&reserved=0
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C5b7ab8201190466822d808d6e8b27112%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636952250440875188&sdata=5GD9W1AzFE837vinQ1oVWZr7%2FRRad1YqY9DpIkSVYIk%3D&reserved=0
> > >
> > >
> > >
> >
> >
> >
>
>
>
Re: Language improvements
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Your summary of my opinion is not correct.
If Vector-as-array is what the current develop branch output is, I am unable to understand how that output is incorrect or poses any risks for anyone who knows they will not need runtime type-checking or runtime fixed-length checking. And thus, it should remain an option. For sure, it was good enough for at least two production apps.
If you are specifically referring to the use of Vector in the Strand, it occurred to me that someone could add another option to inject a type-check before every push on the Vector-as-Array. I think that would allow us to continue to use Vector in the Strand at a cost much less than 2K. And allow many others to get type-checking on push as well. Or, as we discussed earlier, we can just stop using Vector in the Strand.
If you are saying that the risk and harm to the community will come when someone tries to add a bead to the strand at runtime that was instantiated in a way that was not testable at development time, then I guess we will have to agree to disagree on how important that is. IMO, that runtime checking should be PAYG, and I would much rather that we spend time devising a scheme to allow folks to opt-in to runtime checking than tell folks that they must carry around extra code just-in-case someone else needs runtime checking. It could be something as brute force as specifying files in a compiler option where the compiler will replace "goog.DEBUG" with "true". Specific to the strand, yet another option could just be a bead that watches for beadAdded events and checks for IBead. Could be we find a way to replace Vector-as-Array code in libraries with the Vector implementation you've written.
Or maybe, we should spend more time getting the SWF versions of the framework running well enough to have RoyaleUnit or some test automation run your app in the Flash/AIR runtimes so lots more things get checked (missing interface members, other type-checks, etc).
Regardless, it is still great that you've created a runtime-checking implementation of Vector for those who need it.
We do not need to reach a collaborative decision that is A or B. Why should we think we know what our users really need? We provide options/choices so the users can decide for themselves. And invite someone else to come up with even a better solution or solutions.
My 2 cents,
-Alex
On 6/3/19, 11:04 PM, "Greg Dove" <gr...@gmail.com> wrote:
Hi Alex, this will be my last message in this thread.
"The whole point of giving choices is to avoid having to spend so many
emails trying to reach a decision. "
Alex, I really don't understand your stance. The focus of the recent
discussion has been on the choices themselves... concerns about their
potential risks, along with ideas for improvements and code quality.
It sounds like you are saying that we can't talk about improving the
choices we already had, because if they exist that is all that matters.
As far as I understand, the point of these email discussions is to reach
the best quality collaborative decisions.
I don't enjoy the process myself. It's inefficient. But we have an
obligation to be collaborative (I think?). Expressing something along the
lines of 'just do it and move on' does not seem to be that.
I don't care about any of these things in terms of how it affects me
personally, I have only pursued the topic in relation to what I think will
help Royale be successful.
The only way I can interpret your replies thus far is:
More options for optimization are always better, even if they might present
possible risks that could harm the community. We deal with those risks by
issuing warnings.
Specifically, in this case, a library developer being able to dictate
certain optimization(s) that should be used by (and any associated risks
that should be accepted by) the application developer is not unacceptable.
-Your approach to mitigation of the above risks will be for us to warn
people not to do the specific things that could cause the problems in the
first place (from your comment about tools, risks, and documentation).
Something like:
'Don't use any emulation classes in library code unless your emulation
class is Array, and if it is Array, don't expose the Vector type on any
public or protected api surface because it will be a misleading
representation of the type to the user of that api'
Is that a fair summary?
It should be not surprise to you that I personally think the above is
confusing and avoidable, because I consider that there are (and will be)
better options that achieve the same optimization results. But I understand
that you don't, and I can accept that. So I will make one last attempt to
find something that I think is middle ground...
Vector-as-Array is just a special case of the emulationClass approach.
The only middle ground I can think of with regard to reducing the risk is
to have the 'emulationClass' approach is to actually re-map the type in the
javascript output, so the swc typing actually represents the type it has
been transformed to.
This means if people don't follow the above instructions and the type is
exposed on an api surface then it is not misrepresented to unsuspecting
users via the swc that has the optimization. Does that make any sense?
I have no idea at this point if this is easy to do or not. But it would
address the main things that worry me about this (again, not for me, for
royale in general). I only got to this idea out of frustration, although
perhaps it could be considered obvious in retrospect.
I'm not able to tackle this in the near term but I will be happy to pursue
it at some point if you can agree it is a good compromise ( I hope it might
be). As I said, I won't continue any more in this thread. If you like it
please let me know, otherwise I officially give up.
For now, I will try to find time to add the Vector-as-Array back in
sometime later this week. I will do it inside the vectorEmulationClass code
branches in the compiler as a special case of ' vectorEmulationClass '.
Once I have that done and working I will merge.
On Sat, Jun 1, 2019 at 8:26 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> Greg, you are still trying to use the language conformance argument. This
> is not an issue of language conformance, it is an issue of optimization.
> Code paths not needed should not be downloaded. Every app development tool
> I've used that offers optimizations offers optimization levels and
> documentation of risks.
>
> There is a disagreement on how to implement Vector in JS as well. The
> whole point of giving choices is to avoid having to spend so many emails
> trying to reach a decision. Just provide choices so we can move on. Every
> argument you make below is an argument for giving choices.
>
> -Alex
>
> On 5/30/19, 9:03 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> "And so we will stop using Vector and migrate to using a plain Array.
> That
> agreement proves that the proposed changes are not right." We will
> effectively encourage others to do the same.
>
> It does not prove that at all, Alex. It depends on the criteria, and we
> have no commonly accepted guiding principles for what is 'right' here.
> At least one of us believes that it is more correct that (in the
> absence of
> other proposed options) it be an Array in the original code.
> If you take a step back and look at it from a broader perspective, it
> can
> be equally true to say 'This agreement proves that the original
> implementation was not right'.
> Firstly, I don't think Vector type was providing any benefit in this
> case
> in the first place (but that alone is not a reason to change it,
> awareness
> that it 'costs more' would however be a valid reason if there are no
> benefits to using it).
> Secondly, the collaborative outcome resulting in the use of explicit
> Array
> and the goog.DEBUG check is better than the original Vector-as-Array
> output
> because it offers the runtime type safety that was missing because it
> was
> not behaving like a Vector - and it retains the advantage of
> zero-weight in
> release build. Making these changes *is* a form of optimization based
> on
> using options currently available, it just happens to be hand-coded
> and not
> compiler-generated.
> I know it's at least a little bit useful in its new form, because prior
> testing with the branch level Vector implementation flagged a
> non-conforming IBead in the 2nd app I tested it with, something that
> was
> not found by the original 'Array' implementation.
> SWF testing in parallel would have caught that too, but is not a
> realistic
> assumption to have that as part of the workflow for checking runtime
> behavior anymore, so this 'Array with debug-only typecheck' in
> javascript
> is a good outcome.
> In this case, going back to Vector-as-Array output without making the
> other
> change would be a step backwards.
>
> That is however just one specific case, and I needed to present what I
> believe is a more balanced view of that... but I will not focus on it
> in
> any further discussion.
> I do understand that your point is intended to be more general.
> In general, and *by definition*, the cases where you want Vector to be
> Array without adverse consequences are always cases where it can also
> *be*
> Array in the original as3 code. If the only justification for it being
> a
> Vector in as3 code is 'compile-time type safety', then the proposed
> alternative from Harbs and Josh is a better option because it retains
> the
> benefits you seek and is a better quality cross-target representation
> for
> this specific sort of requirement (it will also provide more benefits:
> most
> Vector methods do not have compile-time type safety because most their
> method signatures do not specify :T types, I hope the proposed
> alternative
> might address that).
> For the performance-oriented numeric types, which is another thing
> that has
> been raised, maybe Josh can somehow include that with the typed Arrays
> feature as he suggested, maybe not. If yes, then great, but if not, I
> am
> happy to explore other options for that.
>
> What I'd really like to hear are your thoughts about the concerns I
> raised
> for the:
> "new whateverclasstheconfigordirectivespecified()"
> approach to doing any of this.
>
> How do you propose to avoid risk to the community and potentially to
> Royale's reputation with release of swcs that can have different
> language-level variations in them (XML, Vector or anything that
> represents
> a core as3 'type')?
> Do we have to warn people not to do that, and then hope that they
> don't? A
> user of that swc doesn't see the emulation class that the swc may
> expose
> without investigating at runtime, they normally only see the type it
> represents, and unless they are warned, they have no reason to assume
> it
> won't do all the things it should. There could also be runtime conflict
> implications when mixing swcs with different emulation decisions, and
> that
> could even add weight overall compared to using one. None of this
> represents stuff that can't be figured out and addressed by developers
> who
> have to deal with it. But it seems to me to be something negative,
> which
> would be better to avoid.
>
> I think you are indicating the same desire to avoid this problem by
> saying
> that you want to specify things by 'the swc' you add (e.g. XML
> replacement)... but that can be too late, because even if an alternate
> emulation class itself is not bundled into a swc's code, all the calls
> to
> instantiate it are, which reflect its distinct package name and class
> name.
> I can envisage ways to achieve optimization and to avoid risks for the
> general case, but only if the instantiation calls for these language
> level
> emulations can never vary throughout the entire codebase (all swcs
> included), and the 'optimization' is therefore largely driven from the
> application build, and not dictated at swc level. Maybe swc libraries
> could
> be advertised as being compatible with some well-known optimizations in
> this case, it could even be a 'marketing' claim for the swc.
> The most appealing optimization solution (to me) would be one that
> takes
> more advantage of GCC (which I consider will be 'safer', and also least
> effort for the developer) when the application gets built, instead of
> actually changing the content of individual methods (for example) in
> 'lite'
> versions of replacement classes. However, I can see that doing the
> latter
> (or both) should also be possible and should not be much different, I
> think, from a regular monkey-patch approach, or from your desire for
> swc
> level replacement - but it only works if there is no variation in the
> actual naming of the classes that are being 'patched' (whether its via
> an
> alternate XML-like swc as a direct substitute for the standard one, or
> a
> local monkey patch). Maybe I'm missing something that is obvious to
> you...
> please tell me if I am.
>
>
> On Fri, May 31, 2019 at 6:37 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > It is pretty simple to me. The proposed Vector implementation is
> heavy
> > enough that we all agree that we don't want to use it for just one
> use case
> > in the Strand. And so we will stop using Vector and migrate to
> using a
> > plain Array. That agreement proves that the proposed changes are not
> > right. We will effectively encourage others to do the same.
> >
> > It would be much better if Royale had a way for developers to
> specify that
> > the one use of Vector in the Strand should be converted to plain
> Array by
> > the compiler and other uses could use the proposed Vector. That's
> how
> > optimization should be made available for all kinds of code in
> Royale, not
> > just for Vector.
> >
> > The current Vector output in the develop branch is low cost and fully
> > functional for some uses cases. As long as that output is still
> available
> > as a compiler option then having other output fine.
> >
> > I still haven't found time to look at the actual proposed changes,
> but I
> > would strongly prefer that, instead of having to modify compiler
> output
> > each time someone proposes a different Vector implementation, that
> the
> > changes can all be done by which SWC you choose for your Vector
> > implementation. There are other places in the compiler where you can
> > choose the class to use for Binding or ClassFactory. Hopefully the
> same
> > approach is being used for Vector. Ideally, the compile would just
> output
> > "new whateverclasstheconfigordirectivespecified()" and then just
> output the
> > usual push/pop/index calls and so it could just be plain Array where
> > specified or the proposed Vector and some other Vector someday.
> >
> > This is a case were "there is no one right way". And when we have
> those
> > situations, we must offer choices.
> >
> > -Alex
> >
> > On 5/30/19, 1:34 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > Hi,
> >
> > @Alex Harui <ah...@adobe.com> I think you misunderstood me.
> I'm not
> > saying
> > we should "remove choices". What I say is that we have finally a
> more
> > robust implementation and we can evolve to have more choices
> from that
> > point. I think continue from that safe point will give us many
> > benefits. So
> > I want those choices. What I don't want is to wait to make it
> perfect
> > to
> > merge. As I said before perfection is enemy of the progress.
> >
> > An important point I can't agree with you: Why we don't use
> Vector in
> > our
> > production App? Cause we can't. To do that we need: a) Greg
> changes
> > merged,
> > b) make AMF understand Vectors (still to be done to make Vector
> usable
> > for
> > us). Without both points Vectors are not an option for us. So I
> think
> > the
> > premise of "we have 2 apps in production without Vectors" are not
> > right. We
> > don't have still Jewel DataGrid, or Swiz Global Dispatcher, and
> that
> > does
> > not mean it's ok for us. Is just we still don't have it, but
> making us
> > to
> > make our product without all of that is a serious issue that we
> need to
> > workaround in some way. But we can do that as something
> "temporal",
> > due to
> > current Royale limitations. But our goal is to have all that,
> > Vector-AMF
> > included :)
> >
> > For this reason, I prefer to have Greg's Vector now, since it
> makes our
> > production App be one step closer to remove current workarounds
> :)
> > And I'm sure that not having a Vector solution like this, could
> be a
> > reason
> > why some people still didn't try Royale to migrate to this date.
> > So if you ask me or those people for a "priority path", we will
> say
> > "let's
> > get Vector first, then evolve from that to have more choices".
> > That's what I'm saying it's ok to merge now.
> >
> > I'm ok with having Vector as we all know it from AS3 (since is
> > that...AS3
> > Vector, don't forget that, and is what people expect to have at
> first
> > sight, then we can give them more choices and they will
> appreciate for
> > sure), and have as well a new Typed Array too as other proposed
> too.
> > That
> > will be for me options. But we should not wait to make all that
> happen
> > to
> > merge current branch, right?, All that we'll be lots of time to
> make it
> > perfect from day 0.
> >
> > The key concept for me was what Harbs said in his response to
> the end.
> > If
> > you don't use it the impact is 0, not 2-3k, since people don't
> have
> > Vector
> > presence in their codes. So that's PAYG. For that reason it's ok
> for
> > me to
> > merge and continue from that safe point, since we really only get
> > positive
> > things and nothing negative, and since we all agree in the same
> terms,
> > just
> > we need more time to continue evolving it to get to that perfect
> final
> > point.
> >
> >
> >
> >
> > El jue., 30 may. 2019 a las 7:56, Greg Dove (<
> greg.dove@gmail.com>)
> > escribió:
> >
> > > Harbs some quick comments inline...
> > >
> > > On Thu, May 30, 2019 at 4:27 PM Harbs <ha...@gmail.com>
> wrote:
> > >
> > > > The only niggle I have with my approach is that Vector in
> Flash is
> > more
> > > > performant than array, while in JS, it’s going to be the
> other way
> > > around.
> > > > So if someone has a performance-sensitive piece of code, how
> > should they
> > > > write it so it outputs as performant as possible on both
> platforms?
> > > >
> > > > Vector in flash is only substantially faster for its 3
> numeric
> > types
> > > which
> > > are optimized. It is (slightly) slower than Array in other
> cases - I
> > think
> > > it is normal that the extra type checking takes time even in
> native
> > code.
> > > I remember seeing some data which said it was 30% slower for
> some
> > methods
> > > with the non-primitive types, but that may be old.
> > >
> > > In terms of the emulation version, you can get javascript Array
> > speed with
> > > the index access and assignment, which should be a direct copy
> of
> > the same
> > > parts of code that are heavily optimized in flash I think.
> > >
> > > I was running performance tests on the non-debug flash player
> > alongside
> > > javascript. I actually see the regular native javascript Array
> > beating
> > > flash numeric Vectors in Chrome on windows, for the same tasks.
> > Perhaps the
> > > pepper plugin is getting less cpu resource than the browser or
> > something
> > > like that, not sure. I had assumed TypedArrays would be
> faster, but
> > > recently you said you weren't sure because of js engine
> smarts. I
> > will
> > > still check that.
> > >
> > >
> > >
> > > > I have not spent the time looking into the implementation,
> but I
> > think
> > > > there might be some cross-communication. My understanding
> from
> > what Greg
> > > > wrote is that if Vector is not used in an application, there
> will
> > be no
> > > > extra code due to dead code removal. If that’s correct, I
> think
> > we’re in
> > > > agreement that the implementation is fine. Do I understand
> > correctly?
> > > >
> > >
> > > That is correct.
> > >
> > >
> > > >
> > > > Harbs
> > > >
> > > > > On May 30, 2019, at 1:26 AM, Josh Tynjala <
> > joshtynjala@apache.org>
> > > > wrote:
> > > > >
> > > > > I definitely want the default choice to have as few
> surprises as
> > > > possible when it comes to how ActionScript behaves in Royale.
> > We'll never
> > > > have a perfect emulation, of course, but there are things
> that I
> > think
> > > can
> > > > still be improved. At the same time, I think it's perfectly
> valid
> > for
> > > > someone to want to opt into a typed Array that doesn't have
> the
> > runtime
> > > > overhead of Vector and isn't as heavy in file size. I'm wary
> of the
> > > > solution being a custom implementation of Vector with missing
> > features,
> > > > though. It will lead to confusion, even if it's opt-in.
> > > > >
> > > > > What Harbs suggested seems like a smart way to go. Rather
> than
> > having a
> > > > separate Vector implementation that doesn't work as
> developers are
> > used
> > > to,
> > > > a new variation of Array that has compile-time type checks
> but no
> > runtime
> > > > checks sounds like a more elegant solution. Like Vector
> works in
> > Royale
> > > > today, it can compile down to a regular JS Array, but at
> > compile-time,
> > > we'd
> > > > have some extra safety and could even possibly cast back and
> forth
> > with
> > > > untyped Arrays (which we can't do with Vector).
> > > > >
> > > > > - Josh
> > > > >
> > > > > On 2019/05/29 18:07:31, Alex Harui
> <ah...@adobe.com.INVALID>
> > wrote:
> > > > >> We must not eliminate choices.
> > > > >>
> > > > >> I still haven't had time to look at the branch.
> > > > >>
> > > > >> There must be away to avoid even a 1K cost to those who
> don't
> > need it.
> > > > >>
> > > > >> If there is such a way, then it is fine to merge.
> Otherwise,
> > everyone
> > > > is going to pay 2K to use a Vector when we know at least two
> apps
> > are in
> > > > production without needing that 2k.
> > > > >>
> > > > >> There are too many words being written and no technical
> points
> > being
> > > > made. I will try to resummarize.
> > > > >>
> > > > >> 1) It does not matter how fast your network is. Every
> other
> > app will
> > > > use more bandwidth and when the network gets busy or
> connectivity
> > gets
> > > poor
> > > > (something I see quite frequently where I live) either you
> get
> > your app
> > > to
> > > > run or you run out of time.
> > > > >>
> > > > >> 2) If you are not using some feature of our code, you
> should
> > not have
> > > > to pay for it in download cost. That's PAYG. That would be
> true
> > for
> > > > Vector, XML and even if we had to write a Date
> implementation. It
> > is not
> > > > an issue of non-conforming. It is an issue of
> optimization. If
> > you
> > > aren't
> > > > going to use some feature of E4x you should have the option
> of
> > using code
> > > > that doesn't have those code paths. Same for if we had to
> do Date.
> > > > >>
> > > > >> We know that if you don't need runtime-type checking and
> > fixed-length
> > > > checking that a plain Array is just fine and 2K cheaper.
> Let's
> > give
> > > folks
> > > > the option to do that.
> > > > >>
> > > > >> I will repeat that I do not have any objection to having
> a full
> > Vector
> > > > implementation with runtime type-checking and fixed length
> > checking be
> > > the
> > > > default choice as long as folks can optimize back to using
> the
> > plain
> > > Array
> > > > code we use now.
> > > > >>
> > > > >> For the one Vector we currently have in all apps for the
> > Strand, it
> > > > might be time to change that to an array and check the type
> (in
> > > debug-only
> > > > code) on addBead. Either that or we add compiler options so
> that
> > one
> > > > Vector gets optimized to the current plain Array code.
> > > > >>
> > > > >> It is not a technical argument to classify Vector as
> "Language"
> > and
> > > > therefore somehow an exception to being optimizable.
> > > > >>
> > > > >> My 2 cents,
> > > > >> -Alex
> > > > >>
> > > > >>
> > > > >> On 5/28/19, 2:59 AM, "Carlos Rovira" <
> carlosrovira@apache.org>
> > > wrote:
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I think that we all agree in most of the things, and
> > although we're
> > > > >> discussing some particularities on how to solve, my
> opinion
> > is that
> > > > those
> > > > >> particularities can be solved after merging Language
> > improvements
> > > > branch.
> > > > >> We all agree we need this Vector (and other
> improvements in
> > this
> > > > branch)?.
> > > > >> So, after that merge folks wanting to improve, let's
> say,
> > > Vector(for
> > > > >> example) even more with new choices can do that without
> > problem and
> > > > will
> > > > >> make it even better.
> > > > >>
> > > > >> Are we ok with that?
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> El mar., 28 may. 2019 a las 11:07, Harbs (<
> > harbs.lists@gmail.com>)
> > > > escribió:
> > > > >>
> > > > >>>
> > > > >>>> On May 28, 2019, at 11:12 AM, Greg Dove <
> greg.dove@gmail.com>
> > > wrote:
> > > > >>>>
> > > > >>>>> "I personally have never used length checking in
> Vector. Nor
> > was
> > > > runtime
> > > > >>>>> type checking on Vectors important to me. "
> > > > >>>> length checking is automatic in flash. I don't know
> that you
> > 'use'
> > > > it...
> > > > >>> it
> > > > >>>> is just there.
> > > > >>>
> > > > >>> True. What I meant is that I never used fixed length
> Vectors.
> > > > >>>
> > > > >>>> In javascript I expect it would most often be switched
> off in
> > all
> > > > release
> > > > >>>> builds, but having it on by default provides another
> check of
> > > > something
> > > > >>>> that could provide a vital clue to help people figuring
> out
> > problems
> > > > in
> > > > >>>> code.
> > > > >>>> So far each 'stronger typing' feature added in the last
> few
> > months
> > > has
> > > > >>>> revealed potential issues or - most often - bad code
> that was
> > > working
> > > > >>> when
> > > > >>>> it should not
> > > > >>>
> > > > >>> Good points, and one that argues for the ability to have
> these
> > checks
> > > > >>> while debugging and have the run-time code removed on
> release.
> > > > >>>
> > > > >>>> One thing about the mxml stuff is that it gets
> processed in a
> > way
> > > > that is
> > > > >>>> untyped.
> > > > >>>
> > > > >>>
> > > > >>> Agree. I do wish there was some way for MXML to be output
> > “better”
> > > > where
> > > > >>> minified vars could “just work” and types could be better
> > inferred
> > > > from the
> > > > >>> MXML files.
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Carlos Rovira
> > > > >>
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C5b7ab8201190466822d808d6e8b27112%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636952250440875188&sdata=5GD9W1AzFE837vinQ1oVWZr7%2FRRad1YqY9DpIkSVYIk%3D&reserved=0
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C5b7ab8201190466822d808d6e8b27112%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636952250440875188&sdata=5GD9W1AzFE837vinQ1oVWZr7%2FRRad1YqY9DpIkSVYIk%3D&reserved=0
> >
> >
> >
>
>
>
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
Hi Alex, this will be my last message in this thread.
"The whole point of giving choices is to avoid having to spend so many
emails trying to reach a decision. "
Alex, I really don't understand your stance. The focus of the recent
discussion has been on the choices themselves... concerns about their
potential risks, along with ideas for improvements and code quality.
It sounds like you are saying that we can't talk about improving the
choices we already had, because if they exist that is all that matters.
As far as I understand, the point of these email discussions is to reach
the best quality collaborative decisions.
I don't enjoy the process myself. It's inefficient. But we have an
obligation to be collaborative (I think?). Expressing something along the
lines of 'just do it and move on' does not seem to be that.
I don't care about any of these things in terms of how it affects me
personally, I have only pursued the topic in relation to what I think will
help Royale be successful.
The only way I can interpret your replies thus far is:
More options for optimization are always better, even if they might present
possible risks that could harm the community. We deal with those risks by
issuing warnings.
Specifically, in this case, a library developer being able to dictate
certain optimization(s) that should be used by (and any associated risks
that should be accepted by) the application developer is not unacceptable.
-Your approach to mitigation of the above risks will be for us to warn
people not to do the specific things that could cause the problems in the
first place (from your comment about tools, risks, and documentation).
Something like:
'Don't use any emulation classes in library code unless your emulation
class is Array, and if it is Array, don't expose the Vector type on any
public or protected api surface because it will be a misleading
representation of the type to the user of that api'
Is that a fair summary?
It should be not surprise to you that I personally think the above is
confusing and avoidable, because I consider that there are (and will be)
better options that achieve the same optimization results. But I understand
that you don't, and I can accept that. So I will make one last attempt to
find something that I think is middle ground...
Vector-as-Array is just a special case of the emulationClass approach.
The only middle ground I can think of with regard to reducing the risk is
to have the 'emulationClass' approach is to actually re-map the type in the
javascript output, so the swc typing actually represents the type it has
been transformed to.
This means if people don't follow the above instructions and the type is
exposed on an api surface then it is not misrepresented to unsuspecting
users via the swc that has the optimization. Does that make any sense?
I have no idea at this point if this is easy to do or not. But it would
address the main things that worry me about this (again, not for me, for
royale in general). I only got to this idea out of frustration, although
perhaps it could be considered obvious in retrospect.
I'm not able to tackle this in the near term but I will be happy to pursue
it at some point if you can agree it is a good compromise ( I hope it might
be). As I said, I won't continue any more in this thread. If you like it
please let me know, otherwise I officially give up.
For now, I will try to find time to add the Vector-as-Array back in
sometime later this week. I will do it inside the vectorEmulationClass code
branches in the compiler as a special case of ' vectorEmulationClass '.
Once I have that done and working I will merge.
On Sat, Jun 1, 2019 at 8:26 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> Greg, you are still trying to use the language conformance argument. This
> is not an issue of language conformance, it is an issue of optimization.
> Code paths not needed should not be downloaded. Every app development tool
> I've used that offers optimizations offers optimization levels and
> documentation of risks.
>
> There is a disagreement on how to implement Vector in JS as well. The
> whole point of giving choices is to avoid having to spend so many emails
> trying to reach a decision. Just provide choices so we can move on. Every
> argument you make below is an argument for giving choices.
>
> -Alex
>
> On 5/30/19, 9:03 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> "And so we will stop using Vector and migrate to using a plain Array.
> That
> agreement proves that the proposed changes are not right." We will
> effectively encourage others to do the same.
>
> It does not prove that at all, Alex. It depends on the criteria, and we
> have no commonly accepted guiding principles for what is 'right' here.
> At least one of us believes that it is more correct that (in the
> absence of
> other proposed options) it be an Array in the original code.
> If you take a step back and look at it from a broader perspective, it
> can
> be equally true to say 'This agreement proves that the original
> implementation was not right'.
> Firstly, I don't think Vector type was providing any benefit in this
> case
> in the first place (but that alone is not a reason to change it,
> awareness
> that it 'costs more' would however be a valid reason if there are no
> benefits to using it).
> Secondly, the collaborative outcome resulting in the use of explicit
> Array
> and the goog.DEBUG check is better than the original Vector-as-Array
> output
> because it offers the runtime type safety that was missing because it
> was
> not behaving like a Vector - and it retains the advantage of
> zero-weight in
> release build. Making these changes *is* a form of optimization based
> on
> using options currently available, it just happens to be hand-coded
> and not
> compiler-generated.
> I know it's at least a little bit useful in its new form, because prior
> testing with the branch level Vector implementation flagged a
> non-conforming IBead in the 2nd app I tested it with, something that
> was
> not found by the original 'Array' implementation.
> SWF testing in parallel would have caught that too, but is not a
> realistic
> assumption to have that as part of the workflow for checking runtime
> behavior anymore, so this 'Array with debug-only typecheck' in
> javascript
> is a good outcome.
> In this case, going back to Vector-as-Array output without making the
> other
> change would be a step backwards.
>
> That is however just one specific case, and I needed to present what I
> believe is a more balanced view of that... but I will not focus on it
> in
> any further discussion.
> I do understand that your point is intended to be more general.
> In general, and *by definition*, the cases where you want Vector to be
> Array without adverse consequences are always cases where it can also
> *be*
> Array in the original as3 code. If the only justification for it being
> a
> Vector in as3 code is 'compile-time type safety', then the proposed
> alternative from Harbs and Josh is a better option because it retains
> the
> benefits you seek and is a better quality cross-target representation
> for
> this specific sort of requirement (it will also provide more benefits:
> most
> Vector methods do not have compile-time type safety because most their
> method signatures do not specify :T types, I hope the proposed
> alternative
> might address that).
> For the performance-oriented numeric types, which is another thing
> that has
> been raised, maybe Josh can somehow include that with the typed Arrays
> feature as he suggested, maybe not. If yes, then great, but if not, I
> am
> happy to explore other options for that.
>
> What I'd really like to hear are your thoughts about the concerns I
> raised
> for the:
> "new whateverclasstheconfigordirectivespecified()"
> approach to doing any of this.
>
> How do you propose to avoid risk to the community and potentially to
> Royale's reputation with release of swcs that can have different
> language-level variations in them (XML, Vector or anything that
> represents
> a core as3 'type')?
> Do we have to warn people not to do that, and then hope that they
> don't? A
> user of that swc doesn't see the emulation class that the swc may
> expose
> without investigating at runtime, they normally only see the type it
> represents, and unless they are warned, they have no reason to assume
> it
> won't do all the things it should. There could also be runtime conflict
> implications when mixing swcs with different emulation decisions, and
> that
> could even add weight overall compared to using one. None of this
> represents stuff that can't be figured out and addressed by developers
> who
> have to deal with it. But it seems to me to be something negative,
> which
> would be better to avoid.
>
> I think you are indicating the same desire to avoid this problem by
> saying
> that you want to specify things by 'the swc' you add (e.g. XML
> replacement)... but that can be too late, because even if an alternate
> emulation class itself is not bundled into a swc's code, all the calls
> to
> instantiate it are, which reflect its distinct package name and class
> name.
> I can envisage ways to achieve optimization and to avoid risks for the
> general case, but only if the instantiation calls for these language
> level
> emulations can never vary throughout the entire codebase (all swcs
> included), and the 'optimization' is therefore largely driven from the
> application build, and not dictated at swc level. Maybe swc libraries
> could
> be advertised as being compatible with some well-known optimizations in
> this case, it could even be a 'marketing' claim for the swc.
> The most appealing optimization solution (to me) would be one that
> takes
> more advantage of GCC (which I consider will be 'safer', and also least
> effort for the developer) when the application gets built, instead of
> actually changing the content of individual methods (for example) in
> 'lite'
> versions of replacement classes. However, I can see that doing the
> latter
> (or both) should also be possible and should not be much different, I
> think, from a regular monkey-patch approach, or from your desire for
> swc
> level replacement - but it only works if there is no variation in the
> actual naming of the classes that are being 'patched' (whether its via
> an
> alternate XML-like swc as a direct substitute for the standard one, or
> a
> local monkey patch). Maybe I'm missing something that is obvious to
> you...
> please tell me if I am.
>
>
> On Fri, May 31, 2019 at 6:37 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> > It is pretty simple to me. The proposed Vector implementation is
> heavy
> > enough that we all agree that we don't want to use it for just one
> use case
> > in the Strand. And so we will stop using Vector and migrate to
> using a
> > plain Array. That agreement proves that the proposed changes are not
> > right. We will effectively encourage others to do the same.
> >
> > It would be much better if Royale had a way for developers to
> specify that
> > the one use of Vector in the Strand should be converted to plain
> Array by
> > the compiler and other uses could use the proposed Vector. That's
> how
> > optimization should be made available for all kinds of code in
> Royale, not
> > just for Vector.
> >
> > The current Vector output in the develop branch is low cost and fully
> > functional for some uses cases. As long as that output is still
> available
> > as a compiler option then having other output fine.
> >
> > I still haven't found time to look at the actual proposed changes,
> but I
> > would strongly prefer that, instead of having to modify compiler
> output
> > each time someone proposes a different Vector implementation, that
> the
> > changes can all be done by which SWC you choose for your Vector
> > implementation. There are other places in the compiler where you can
> > choose the class to use for Binding or ClassFactory. Hopefully the
> same
> > approach is being used for Vector. Ideally, the compile would just
> output
> > "new whateverclasstheconfigordirectivespecified()" and then just
> output the
> > usual push/pop/index calls and so it could just be plain Array where
> > specified or the proposed Vector and some other Vector someday.
> >
> > This is a case were "there is no one right way". And when we have
> those
> > situations, we must offer choices.
> >
> > -Alex
> >
> > On 5/30/19, 1:34 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> >
> > Hi,
> >
> > @Alex Harui <ah...@adobe.com> I think you misunderstood me.
> I'm not
> > saying
> > we should "remove choices". What I say is that we have finally a
> more
> > robust implementation and we can evolve to have more choices
> from that
> > point. I think continue from that safe point will give us many
> > benefits. So
> > I want those choices. What I don't want is to wait to make it
> perfect
> > to
> > merge. As I said before perfection is enemy of the progress.
> >
> > An important point I can't agree with you: Why we don't use
> Vector in
> > our
> > production App? Cause we can't. To do that we need: a) Greg
> changes
> > merged,
> > b) make AMF understand Vectors (still to be done to make Vector
> usable
> > for
> > us). Without both points Vectors are not an option for us. So I
> think
> > the
> > premise of "we have 2 apps in production without Vectors" are not
> > right. We
> > don't have still Jewel DataGrid, or Swiz Global Dispatcher, and
> that
> > does
> > not mean it's ok for us. Is just we still don't have it, but
> making us
> > to
> > make our product without all of that is a serious issue that we
> need to
> > workaround in some way. But we can do that as something
> "temporal",
> > due to
> > current Royale limitations. But our goal is to have all that,
> > Vector-AMF
> > included :)
> >
> > For this reason, I prefer to have Greg's Vector now, since it
> makes our
> > production App be one step closer to remove current workarounds
> :)
> > And I'm sure that not having a Vector solution like this, could
> be a
> > reason
> > why some people still didn't try Royale to migrate to this date.
> > So if you ask me or those people for a "priority path", we will
> say
> > "let's
> > get Vector first, then evolve from that to have more choices".
> > That's what I'm saying it's ok to merge now.
> >
> > I'm ok with having Vector as we all know it from AS3 (since is
> > that...AS3
> > Vector, don't forget that, and is what people expect to have at
> first
> > sight, then we can give them more choices and they will
> appreciate for
> > sure), and have as well a new Typed Array too as other proposed
> too.
> > That
> > will be for me options. But we should not wait to make all that
> happen
> > to
> > merge current branch, right?, All that we'll be lots of time to
> make it
> > perfect from day 0.
> >
> > The key concept for me was what Harbs said in his response to
> the end.
> > If
> > you don't use it the impact is 0, not 2-3k, since people don't
> have
> > Vector
> > presence in their codes. So that's PAYG. For that reason it's ok
> for
> > me to
> > merge and continue from that safe point, since we really only get
> > positive
> > things and nothing negative, and since we all agree in the same
> terms,
> > just
> > we need more time to continue evolving it to get to that perfect
> final
> > point.
> >
> >
> >
> >
> > El jue., 30 may. 2019 a las 7:56, Greg Dove (<
> greg.dove@gmail.com>)
> > escribió:
> >
> > > Harbs some quick comments inline...
> > >
> > > On Thu, May 30, 2019 at 4:27 PM Harbs <ha...@gmail.com>
> wrote:
> > >
> > > > The only niggle I have with my approach is that Vector in
> Flash is
> > more
> > > > performant than array, while in JS, it’s going to be the
> other way
> > > around.
> > > > So if someone has a performance-sensitive piece of code, how
> > should they
> > > > write it so it outputs as performant as possible on both
> platforms?
> > > >
> > > > Vector in flash is only substantially faster for its 3
> numeric
> > types
> > > which
> > > are optimized. It is (slightly) slower than Array in other
> cases - I
> > think
> > > it is normal that the extra type checking takes time even in
> native
> > code.
> > > I remember seeing some data which said it was 30% slower for
> some
> > methods
> > > with the non-primitive types, but that may be old.
> > >
> > > In terms of the emulation version, you can get javascript Array
> > speed with
> > > the index access and assignment, which should be a direct copy
> of
> > the same
> > > parts of code that are heavily optimized in flash I think.
> > >
> > > I was running performance tests on the non-debug flash player
> > alongside
> > > javascript. I actually see the regular native javascript Array
> > beating
> > > flash numeric Vectors in Chrome on windows, for the same tasks.
> > Perhaps the
> > > pepper plugin is getting less cpu resource than the browser or
> > something
> > > like that, not sure. I had assumed TypedArrays would be
> faster, but
> > > recently you said you weren't sure because of js engine
> smarts. I
> > will
> > > still check that.
> > >
> > >
> > >
> > > > I have not spent the time looking into the implementation,
> but I
> > think
> > > > there might be some cross-communication. My understanding
> from
> > what Greg
> > > > wrote is that if Vector is not used in an application, there
> will
> > be no
> > > > extra code due to dead code removal. If that’s correct, I
> think
> > we’re in
> > > > agreement that the implementation is fine. Do I understand
> > correctly?
> > > >
> > >
> > > That is correct.
> > >
> > >
> > > >
> > > > Harbs
> > > >
> > > > > On May 30, 2019, at 1:26 AM, Josh Tynjala <
> > joshtynjala@apache.org>
> > > > wrote:
> > > > >
> > > > > I definitely want the default choice to have as few
> surprises as
> > > > possible when it comes to how ActionScript behaves in Royale.
> > We'll never
> > > > have a perfect emulation, of course, but there are things
> that I
> > think
> > > can
> > > > still be improved. At the same time, I think it's perfectly
> valid
> > for
> > > > someone to want to opt into a typed Array that doesn't have
> the
> > runtime
> > > > overhead of Vector and isn't as heavy in file size. I'm wary
> of the
> > > > solution being a custom implementation of Vector with missing
> > features,
> > > > though. It will lead to confusion, even if it's opt-in.
> > > > >
> > > > > What Harbs suggested seems like a smart way to go. Rather
> than
> > having a
> > > > separate Vector implementation that doesn't work as
> developers are
> > used
> > > to,
> > > > a new variation of Array that has compile-time type checks
> but no
> > runtime
> > > > checks sounds like a more elegant solution. Like Vector
> works in
> > Royale
> > > > today, it can compile down to a regular JS Array, but at
> > compile-time,
> > > we'd
> > > > have some extra safety and could even possibly cast back and
> forth
> > with
> > > > untyped Arrays (which we can't do with Vector).
> > > > >
> > > > > - Josh
> > > > >
> > > > > On 2019/05/29 18:07:31, Alex Harui
> <ah...@adobe.com.INVALID>
> > wrote:
> > > > >> We must not eliminate choices.
> > > > >>
> > > > >> I still haven't had time to look at the branch.
> > > > >>
> > > > >> There must be away to avoid even a 1K cost to those who
> don't
> > need it.
> > > > >>
> > > > >> If there is such a way, then it is fine to merge.
> Otherwise,
> > everyone
> > > > is going to pay 2K to use a Vector when we know at least two
> apps
> > are in
> > > > production without needing that 2k.
> > > > >>
> > > > >> There are too many words being written and no technical
> points
> > being
> > > > made. I will try to resummarize.
> > > > >>
> > > > >> 1) It does not matter how fast your network is. Every
> other
> > app will
> > > > use more bandwidth and when the network gets busy or
> connectivity
> > gets
> > > poor
> > > > (something I see quite frequently where I live) either you
> get
> > your app
> > > to
> > > > run or you run out of time.
> > > > >>
> > > > >> 2) If you are not using some feature of our code, you
> should
> > not have
> > > > to pay for it in download cost. That's PAYG. That would be
> true
> > for
> > > > Vector, XML and even if we had to write a Date
> implementation. It
> > is not
> > > > an issue of non-conforming. It is an issue of
> optimization. If
> > you
> > > aren't
> > > > going to use some feature of E4x you should have the option
> of
> > using code
> > > > that doesn't have those code paths. Same for if we had to
> do Date.
> > > > >>
> > > > >> We know that if you don't need runtime-type checking and
> > fixed-length
> > > > checking that a plain Array is just fine and 2K cheaper.
> Let's
> > give
> > > folks
> > > > the option to do that.
> > > > >>
> > > > >> I will repeat that I do not have any objection to having
> a full
> > Vector
> > > > implementation with runtime type-checking and fixed length
> > checking be
> > > the
> > > > default choice as long as folks can optimize back to using
> the
> > plain
> > > Array
> > > > code we use now.
> > > > >>
> > > > >> For the one Vector we currently have in all apps for the
> > Strand, it
> > > > might be time to change that to an array and check the type
> (in
> > > debug-only
> > > > code) on addBead. Either that or we add compiler options so
> that
> > one
> > > > Vector gets optimized to the current plain Array code.
> > > > >>
> > > > >> It is not a technical argument to classify Vector as
> "Language"
> > and
> > > > therefore somehow an exception to being optimizable.
> > > > >>
> > > > >> My 2 cents,
> > > > >> -Alex
> > > > >>
> > > > >>
> > > > >> On 5/28/19, 2:59 AM, "Carlos Rovira" <
> carlosrovira@apache.org>
> > > wrote:
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I think that we all agree in most of the things, and
> > although we're
> > > > >> discussing some particularities on how to solve, my
> opinion
> > is that
> > > > those
> > > > >> particularities can be solved after merging Language
> > improvements
> > > > branch.
> > > > >> We all agree we need this Vector (and other
> improvements in
> > this
> > > > branch)?.
> > > > >> So, after that merge folks wanting to improve, let's
> say,
> > > Vector(for
> > > > >> example) even more with new choices can do that without
> > problem and
> > > > will
> > > > >> make it even better.
> > > > >>
> > > > >> Are we ok with that?
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> El mar., 28 may. 2019 a las 11:07, Harbs (<
> > harbs.lists@gmail.com>)
> > > > escribió:
> > > > >>
> > > > >>>
> > > > >>>> On May 28, 2019, at 11:12 AM, Greg Dove <
> greg.dove@gmail.com>
> > > wrote:
> > > > >>>>
> > > > >>>>> "I personally have never used length checking in
> Vector. Nor
> > was
> > > > runtime
> > > > >>>>> type checking on Vectors important to me. "
> > > > >>>> length checking is automatic in flash. I don't know
> that you
> > 'use'
> > > > it...
> > > > >>> it
> > > > >>>> is just there.
> > > > >>>
> > > > >>> True. What I meant is that I never used fixed length
> Vectors.
> > > > >>>
> > > > >>>> In javascript I expect it would most often be switched
> off in
> > all
> > > > release
> > > > >>>> builds, but having it on by default provides another
> check of
> > > > something
> > > > >>>> that could provide a vital clue to help people figuring
> out
> > problems
> > > > in
> > > > >>>> code.
> > > > >>>> So far each 'stronger typing' feature added in the last
> few
> > months
> > > has
> > > > >>>> revealed potential issues or - most often - bad code
> that was
> > > working
> > > > >>> when
> > > > >>>> it should not
> > > > >>>
> > > > >>> Good points, and one that argues for the ability to have
> these
> > checks
> > > > >>> while debugging and have the run-time code removed on
> release.
> > > > >>>
> > > > >>>> One thing about the mxml stuff is that it gets
> processed in a
> > way
> > > > that is
> > > > >>>> untyped.
> > > > >>>
> > > > >>>
> > > > >>> Agree. I do wish there was some way for MXML to be output
> > “better”
> > > > where
> > > > >>> minified vars could “just work” and types could be better
> > inferred
> > > > from the
> > > > >>> MXML files.
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Carlos Rovira
> > > > >>
> > > >
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7b5824f745304f9e222308d6e57cfac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948722282899722&sdata=T5XYilhl3fSjVqu60ZolwQWXIczCR5w73axIKMd%2BDS0%3D&reserved=0
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7b5824f745304f9e222308d6e57cfac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948722282899722&sdata=T5XYilhl3fSjVqu60ZolwQWXIczCR5w73axIKMd%2BDS0%3D&reserved=0
> >
> >
> >
>
>
>
Re: Language improvements
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Greg, you are still trying to use the language conformance argument. This is not an issue of language conformance, it is an issue of optimization. Code paths not needed should not be downloaded. Every app development tool I've used that offers optimizations offers optimization levels and documentation of risks.
There is a disagreement on how to implement Vector in JS as well. The whole point of giving choices is to avoid having to spend so many emails trying to reach a decision. Just provide choices so we can move on. Every argument you make below is an argument for giving choices.
-Alex
On 5/30/19, 9:03 PM, "Greg Dove" <gr...@gmail.com> wrote:
"And so we will stop using Vector and migrate to using a plain Array. That
agreement proves that the proposed changes are not right." We will
effectively encourage others to do the same.
It does not prove that at all, Alex. It depends on the criteria, and we
have no commonly accepted guiding principles for what is 'right' here.
At least one of us believes that it is more correct that (in the absence of
other proposed options) it be an Array in the original code.
If you take a step back and look at it from a broader perspective, it can
be equally true to say 'This agreement proves that the original
implementation was not right'.
Firstly, I don't think Vector type was providing any benefit in this case
in the first place (but that alone is not a reason to change it, awareness
that it 'costs more' would however be a valid reason if there are no
benefits to using it).
Secondly, the collaborative outcome resulting in the use of explicit Array
and the goog.DEBUG check is better than the original Vector-as-Array output
because it offers the runtime type safety that was missing because it was
not behaving like a Vector - and it retains the advantage of zero-weight in
release build. Making these changes *is* a form of optimization based on
using options currently available, it just happens to be hand-coded and not
compiler-generated.
I know it's at least a little bit useful in its new form, because prior
testing with the branch level Vector implementation flagged a
non-conforming IBead in the 2nd app I tested it with, something that was
not found by the original 'Array' implementation.
SWF testing in parallel would have caught that too, but is not a realistic
assumption to have that as part of the workflow for checking runtime
behavior anymore, so this 'Array with debug-only typecheck' in javascript
is a good outcome.
In this case, going back to Vector-as-Array output without making the other
change would be a step backwards.
That is however just one specific case, and I needed to present what I
believe is a more balanced view of that... but I will not focus on it in
any further discussion.
I do understand that your point is intended to be more general.
In general, and *by definition*, the cases where you want Vector to be
Array without adverse consequences are always cases where it can also *be*
Array in the original as3 code. If the only justification for it being a
Vector in as3 code is 'compile-time type safety', then the proposed
alternative from Harbs and Josh is a better option because it retains the
benefits you seek and is a better quality cross-target representation for
this specific sort of requirement (it will also provide more benefits: most
Vector methods do not have compile-time type safety because most their
method signatures do not specify :T types, I hope the proposed alternative
might address that).
For the performance-oriented numeric types, which is another thing that has
been raised, maybe Josh can somehow include that with the typed Arrays
feature as he suggested, maybe not. If yes, then great, but if not, I am
happy to explore other options for that.
What I'd really like to hear are your thoughts about the concerns I raised
for the:
"new whateverclasstheconfigordirectivespecified()"
approach to doing any of this.
How do you propose to avoid risk to the community and potentially to
Royale's reputation with release of swcs that can have different
language-level variations in them (XML, Vector or anything that represents
a core as3 'type')?
Do we have to warn people not to do that, and then hope that they don't? A
user of that swc doesn't see the emulation class that the swc may expose
without investigating at runtime, they normally only see the type it
represents, and unless they are warned, they have no reason to assume it
won't do all the things it should. There could also be runtime conflict
implications when mixing swcs with different emulation decisions, and that
could even add weight overall compared to using one. None of this
represents stuff that can't be figured out and addressed by developers who
have to deal with it. But it seems to me to be something negative, which
would be better to avoid.
I think you are indicating the same desire to avoid this problem by saying
that you want to specify things by 'the swc' you add (e.g. XML
replacement)... but that can be too late, because even if an alternate
emulation class itself is not bundled into a swc's code, all the calls to
instantiate it are, which reflect its distinct package name and class name.
I can envisage ways to achieve optimization and to avoid risks for the
general case, but only if the instantiation calls for these language level
emulations can never vary throughout the entire codebase (all swcs
included), and the 'optimization' is therefore largely driven from the
application build, and not dictated at swc level. Maybe swc libraries could
be advertised as being compatible with some well-known optimizations in
this case, it could even be a 'marketing' claim for the swc.
The most appealing optimization solution (to me) would be one that takes
more advantage of GCC (which I consider will be 'safer', and also least
effort for the developer) when the application gets built, instead of
actually changing the content of individual methods (for example) in 'lite'
versions of replacement classes. However, I can see that doing the latter
(or both) should also be possible and should not be much different, I
think, from a regular monkey-patch approach, or from your desire for swc
level replacement - but it only works if there is no variation in the
actual naming of the classes that are being 'patched' (whether its via an
alternate XML-like swc as a direct substitute for the standard one, or a
local monkey patch). Maybe I'm missing something that is obvious to you...
please tell me if I am.
On Fri, May 31, 2019 at 6:37 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> It is pretty simple to me. The proposed Vector implementation is heavy
> enough that we all agree that we don't want to use it for just one use case
> in the Strand. And so we will stop using Vector and migrate to using a
> plain Array. That agreement proves that the proposed changes are not
> right. We will effectively encourage others to do the same.
>
> It would be much better if Royale had a way for developers to specify that
> the one use of Vector in the Strand should be converted to plain Array by
> the compiler and other uses could use the proposed Vector. That's how
> optimization should be made available for all kinds of code in Royale, not
> just for Vector.
>
> The current Vector output in the develop branch is low cost and fully
> functional for some uses cases. As long as that output is still available
> as a compiler option then having other output fine.
>
> I still haven't found time to look at the actual proposed changes, but I
> would strongly prefer that, instead of having to modify compiler output
> each time someone proposes a different Vector implementation, that the
> changes can all be done by which SWC you choose for your Vector
> implementation. There are other places in the compiler where you can
> choose the class to use for Binding or ClassFactory. Hopefully the same
> approach is being used for Vector. Ideally, the compile would just output
> "new whateverclasstheconfigordirectivespecified()" and then just output the
> usual push/pop/index calls and so it could just be plain Array where
> specified or the proposed Vector and some other Vector someday.
>
> This is a case were "there is no one right way". And when we have those
> situations, we must offer choices.
>
> -Alex
>
> On 5/30/19, 1:34 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi,
>
> @Alex Harui <ah...@adobe.com> I think you misunderstood me. I'm not
> saying
> we should "remove choices". What I say is that we have finally a more
> robust implementation and we can evolve to have more choices from that
> point. I think continue from that safe point will give us many
> benefits. So
> I want those choices. What I don't want is to wait to make it perfect
> to
> merge. As I said before perfection is enemy of the progress.
>
> An important point I can't agree with you: Why we don't use Vector in
> our
> production App? Cause we can't. To do that we need: a) Greg changes
> merged,
> b) make AMF understand Vectors (still to be done to make Vector usable
> for
> us). Without both points Vectors are not an option for us. So I think
> the
> premise of "we have 2 apps in production without Vectors" are not
> right. We
> don't have still Jewel DataGrid, or Swiz Global Dispatcher, and that
> does
> not mean it's ok for us. Is just we still don't have it, but making us
> to
> make our product without all of that is a serious issue that we need to
> workaround in some way. But we can do that as something "temporal",
> due to
> current Royale limitations. But our goal is to have all that,
> Vector-AMF
> included :)
>
> For this reason, I prefer to have Greg's Vector now, since it makes our
> production App be one step closer to remove current workarounds :)
> And I'm sure that not having a Vector solution like this, could be a
> reason
> why some people still didn't try Royale to migrate to this date.
> So if you ask me or those people for a "priority path", we will say
> "let's
> get Vector first, then evolve from that to have more choices".
> That's what I'm saying it's ok to merge now.
>
> I'm ok with having Vector as we all know it from AS3 (since is
> that...AS3
> Vector, don't forget that, and is what people expect to have at first
> sight, then we can give them more choices and they will appreciate for
> sure), and have as well a new Typed Array too as other proposed too.
> That
> will be for me options. But we should not wait to make all that happen
> to
> merge current branch, right?, All that we'll be lots of time to make it
> perfect from day 0.
>
> The key concept for me was what Harbs said in his response to the end.
> If
> you don't use it the impact is 0, not 2-3k, since people don't have
> Vector
> presence in their codes. So that's PAYG. For that reason it's ok for
> me to
> merge and continue from that safe point, since we really only get
> positive
> things and nothing negative, and since we all agree in the same terms,
> just
> we need more time to continue evolving it to get to that perfect final
> point.
>
>
>
>
> El jue., 30 may. 2019 a las 7:56, Greg Dove (<gr...@gmail.com>)
> escribió:
>
> > Harbs some quick comments inline...
> >
> > On Thu, May 30, 2019 at 4:27 PM Harbs <ha...@gmail.com> wrote:
> >
> > > The only niggle I have with my approach is that Vector in Flash is
> more
> > > performant than array, while in JS, it’s going to be the other way
> > around.
> > > So if someone has a performance-sensitive piece of code, how
> should they
> > > write it so it outputs as performant as possible on both platforms?
> > >
> > > Vector in flash is only substantially faster for its 3 numeric
> types
> > which
> > are optimized. It is (slightly) slower than Array in other cases - I
> think
> > it is normal that the extra type checking takes time even in native
> code.
> > I remember seeing some data which said it was 30% slower for some
> methods
> > with the non-primitive types, but that may be old.
> >
> > In terms of the emulation version, you can get javascript Array
> speed with
> > the index access and assignment, which should be a direct copy of
> the same
> > parts of code that are heavily optimized in flash I think.
> >
> > I was running performance tests on the non-debug flash player
> alongside
> > javascript. I actually see the regular native javascript Array
> beating
> > flash numeric Vectors in Chrome on windows, for the same tasks.
> Perhaps the
> > pepper plugin is getting less cpu resource than the browser or
> something
> > like that, not sure. I had assumed TypedArrays would be faster, but
> > recently you said you weren't sure because of js engine smarts. I
> will
> > still check that.
> >
> >
> >
> > > I have not spent the time looking into the implementation, but I
> think
> > > there might be some cross-communication. My understanding from
> what Greg
> > > wrote is that if Vector is not used in an application, there will
> be no
> > > extra code due to dead code removal. If that’s correct, I think
> we’re in
> > > agreement that the implementation is fine. Do I understand
> correctly?
> > >
> >
> > That is correct.
> >
> >
> > >
> > > Harbs
> > >
> > > > On May 30, 2019, at 1:26 AM, Josh Tynjala <
> joshtynjala@apache.org>
> > > wrote:
> > > >
> > > > I definitely want the default choice to have as few surprises as
> > > possible when it comes to how ActionScript behaves in Royale.
> We'll never
> > > have a perfect emulation, of course, but there are things that I
> think
> > can
> > > still be improved. At the same time, I think it's perfectly valid
> for
> > > someone to want to opt into a typed Array that doesn't have the
> runtime
> > > overhead of Vector and isn't as heavy in file size. I'm wary of the
> > > solution being a custom implementation of Vector with missing
> features,
> > > though. It will lead to confusion, even if it's opt-in.
> > > >
> > > > What Harbs suggested seems like a smart way to go. Rather than
> having a
> > > separate Vector implementation that doesn't work as developers are
> used
> > to,
> > > a new variation of Array that has compile-time type checks but no
> runtime
> > > checks sounds like a more elegant solution. Like Vector works in
> Royale
> > > today, it can compile down to a regular JS Array, but at
> compile-time,
> > we'd
> > > have some extra safety and could even possibly cast back and forth
> with
> > > untyped Arrays (which we can't do with Vector).
> > > >
> > > > - Josh
> > > >
> > > > On 2019/05/29 18:07:31, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> > > >> We must not eliminate choices.
> > > >>
> > > >> I still haven't had time to look at the branch.
> > > >>
> > > >> There must be away to avoid even a 1K cost to those who don't
> need it.
> > > >>
> > > >> If there is such a way, then it is fine to merge. Otherwise,
> everyone
> > > is going to pay 2K to use a Vector when we know at least two apps
> are in
> > > production without needing that 2k.
> > > >>
> > > >> There are too many words being written and no technical points
> being
> > > made. I will try to resummarize.
> > > >>
> > > >> 1) It does not matter how fast your network is. Every other
> app will
> > > use more bandwidth and when the network gets busy or connectivity
> gets
> > poor
> > > (something I see quite frequently where I live) either you get
> your app
> > to
> > > run or you run out of time.
> > > >>
> > > >> 2) If you are not using some feature of our code, you should
> not have
> > > to pay for it in download cost. That's PAYG. That would be true
> for
> > > Vector, XML and even if we had to write a Date implementation. It
> is not
> > > an issue of non-conforming. It is an issue of optimization. If
> you
> > aren't
> > > going to use some feature of E4x you should have the option of
> using code
> > > that doesn't have those code paths. Same for if we had to do Date.
> > > >>
> > > >> We know that if you don't need runtime-type checking and
> fixed-length
> > > checking that a plain Array is just fine and 2K cheaper. Let's
> give
> > folks
> > > the option to do that.
> > > >>
> > > >> I will repeat that I do not have any objection to having a full
> Vector
> > > implementation with runtime type-checking and fixed length
> checking be
> > the
> > > default choice as long as folks can optimize back to using the
> plain
> > Array
> > > code we use now.
> > > >>
> > > >> For the one Vector we currently have in all apps for the
> Strand, it
> > > might be time to change that to an array and check the type (in
> > debug-only
> > > code) on addBead. Either that or we add compiler options so that
> one
> > > Vector gets optimized to the current plain Array code.
> > > >>
> > > >> It is not a technical argument to classify Vector as "Language"
> and
> > > therefore somehow an exception to being optimizable.
> > > >>
> > > >> My 2 cents,
> > > >> -Alex
> > > >>
> > > >>
> > > >> On 5/28/19, 2:59 AM, "Carlos Rovira" <ca...@apache.org>
> > wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> I think that we all agree in most of the things, and
> although we're
> > > >> discussing some particularities on how to solve, my opinion
> is that
> > > those
> > > >> particularities can be solved after merging Language
> improvements
> > > branch.
> > > >> We all agree we need this Vector (and other improvements in
> this
> > > branch)?.
> > > >> So, after that merge folks wanting to improve, let's say,
> > Vector(for
> > > >> example) even more with new choices can do that without
> problem and
> > > will
> > > >> make it even better.
> > > >>
> > > >> Are we ok with that?
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> El mar., 28 may. 2019 a las 11:07, Harbs (<
> harbs.lists@gmail.com>)
> > > escribió:
> > > >>
> > > >>>
> > > >>>> On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com>
> > wrote:
> > > >>>>
> > > >>>>> "I personally have never used length checking in Vector. Nor
> was
> > > runtime
> > > >>>>> type checking on Vectors important to me. "
> > > >>>> length checking is automatic in flash. I don't know that you
> 'use'
> > > it...
> > > >>> it
> > > >>>> is just there.
> > > >>>
> > > >>> True. What I meant is that I never used fixed length Vectors.
> > > >>>
> > > >>>> In javascript I expect it would most often be switched off in
> all
> > > release
> > > >>>> builds, but having it on by default provides another check of
> > > something
> > > >>>> that could provide a vital clue to help people figuring out
> problems
> > > in
> > > >>>> code.
> > > >>>> So far each 'stronger typing' feature added in the last few
> months
> > has
> > > >>>> revealed potential issues or - most often - bad code that was
> > working
> > > >>> when
> > > >>>> it should not
> > > >>>
> > > >>> Good points, and one that argues for the ability to have these
> checks
> > > >>> while debugging and have the run-time code removed on release.
> > > >>>
> > > >>>> One thing about the mxml stuff is that it gets processed in a
> way
> > > that is
> > > >>>> untyped.
> > > >>>
> > > >>>
> > > >>> Agree. I do wish there was some way for MXML to be output
> “better”
> > > where
> > > >>> minified vars could “just work” and types could be better
> inferred
> > > from the
> > > >>> MXML files.
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Carlos Rovira
> > > >>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7b5824f745304f9e222308d6e57cfac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948722282899722&sdata=T5XYilhl3fSjVqu60ZolwQWXIczCR5w73axIKMd%2BDS0%3D&reserved=0
> > > >>
> > > >>
> > > >>
> > >
> > >
> >
>
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7b5824f745304f9e222308d6e57cfac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948722282899722&sdata=T5XYilhl3fSjVqu60ZolwQWXIczCR5w73axIKMd%2BDS0%3D&reserved=0
>
>
>
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
"And so we will stop using Vector and migrate to using a plain Array. That
agreement proves that the proposed changes are not right." We will
effectively encourage others to do the same.
It does not prove that at all, Alex. It depends on the criteria, and we
have no commonly accepted guiding principles for what is 'right' here.
At least one of us believes that it is more correct that (in the absence of
other proposed options) it be an Array in the original code.
If you take a step back and look at it from a broader perspective, it can
be equally true to say 'This agreement proves that the original
implementation was not right'.
Firstly, I don't think Vector type was providing any benefit in this case
in the first place (but that alone is not a reason to change it, awareness
that it 'costs more' would however be a valid reason if there are no
benefits to using it).
Secondly, the collaborative outcome resulting in the use of explicit Array
and the goog.DEBUG check is better than the original Vector-as-Array output
because it offers the runtime type safety that was missing because it was
not behaving like a Vector - and it retains the advantage of zero-weight in
release build. Making these changes *is* a form of optimization based on
using options currently available, it just happens to be hand-coded and not
compiler-generated.
I know it's at least a little bit useful in its new form, because prior
testing with the branch level Vector implementation flagged a
non-conforming IBead in the 2nd app I tested it with, something that was
not found by the original 'Array' implementation.
SWF testing in parallel would have caught that too, but is not a realistic
assumption to have that as part of the workflow for checking runtime
behavior anymore, so this 'Array with debug-only typecheck' in javascript
is a good outcome.
In this case, going back to Vector-as-Array output without making the other
change would be a step backwards.
That is however just one specific case, and I needed to present what I
believe is a more balanced view of that... but I will not focus on it in
any further discussion.
I do understand that your point is intended to be more general.
In general, and *by definition*, the cases where you want Vector to be
Array without adverse consequences are always cases where it can also *be*
Array in the original as3 code. If the only justification for it being a
Vector in as3 code is 'compile-time type safety', then the proposed
alternative from Harbs and Josh is a better option because it retains the
benefits you seek and is a better quality cross-target representation for
this specific sort of requirement (it will also provide more benefits: most
Vector methods do not have compile-time type safety because most their
method signatures do not specify :T types, I hope the proposed alternative
might address that).
For the performance-oriented numeric types, which is another thing that has
been raised, maybe Josh can somehow include that with the typed Arrays
feature as he suggested, maybe not. If yes, then great, but if not, I am
happy to explore other options for that.
What I'd really like to hear are your thoughts about the concerns I raised
for the:
"new whateverclasstheconfigordirectivespecified()"
approach to doing any of this.
How do you propose to avoid risk to the community and potentially to
Royale's reputation with release of swcs that can have different
language-level variations in them (XML, Vector or anything that represents
a core as3 'type')?
Do we have to warn people not to do that, and then hope that they don't? A
user of that swc doesn't see the emulation class that the swc may expose
without investigating at runtime, they normally only see the type it
represents, and unless they are warned, they have no reason to assume it
won't do all the things it should. There could also be runtime conflict
implications when mixing swcs with different emulation decisions, and that
could even add weight overall compared to using one. None of this
represents stuff that can't be figured out and addressed by developers who
have to deal with it. But it seems to me to be something negative, which
would be better to avoid.
I think you are indicating the same desire to avoid this problem by saying
that you want to specify things by 'the swc' you add (e.g. XML
replacement)... but that can be too late, because even if an alternate
emulation class itself is not bundled into a swc's code, all the calls to
instantiate it are, which reflect its distinct package name and class name.
I can envisage ways to achieve optimization and to avoid risks for the
general case, but only if the instantiation calls for these language level
emulations can never vary throughout the entire codebase (all swcs
included), and the 'optimization' is therefore largely driven from the
application build, and not dictated at swc level. Maybe swc libraries could
be advertised as being compatible with some well-known optimizations in
this case, it could even be a 'marketing' claim for the swc.
The most appealing optimization solution (to me) would be one that takes
more advantage of GCC (which I consider will be 'safer', and also least
effort for the developer) when the application gets built, instead of
actually changing the content of individual methods (for example) in 'lite'
versions of replacement classes. However, I can see that doing the latter
(or both) should also be possible and should not be much different, I
think, from a regular monkey-patch approach, or from your desire for swc
level replacement - but it only works if there is no variation in the
actual naming of the classes that are being 'patched' (whether its via an
alternate XML-like swc as a direct substitute for the standard one, or a
local monkey patch). Maybe I'm missing something that is obvious to you...
please tell me if I am.
On Fri, May 31, 2019 at 6:37 AM Alex Harui <ah...@adobe.com.invalid> wrote:
> It is pretty simple to me. The proposed Vector implementation is heavy
> enough that we all agree that we don't want to use it for just one use case
> in the Strand. And so we will stop using Vector and migrate to using a
> plain Array. That agreement proves that the proposed changes are not
> right. We will effectively encourage others to do the same.
>
> It would be much better if Royale had a way for developers to specify that
> the one use of Vector in the Strand should be converted to plain Array by
> the compiler and other uses could use the proposed Vector. That's how
> optimization should be made available for all kinds of code in Royale, not
> just for Vector.
>
> The current Vector output in the develop branch is low cost and fully
> functional for some uses cases. As long as that output is still available
> as a compiler option then having other output fine.
>
> I still haven't found time to look at the actual proposed changes, but I
> would strongly prefer that, instead of having to modify compiler output
> each time someone proposes a different Vector implementation, that the
> changes can all be done by which SWC you choose for your Vector
> implementation. There are other places in the compiler where you can
> choose the class to use for Binding or ClassFactory. Hopefully the same
> approach is being used for Vector. Ideally, the compile would just output
> "new whateverclasstheconfigordirectivespecified()" and then just output the
> usual push/pop/index calls and so it could just be plain Array where
> specified or the proposed Vector and some other Vector someday.
>
> This is a case were "there is no one right way". And when we have those
> situations, we must offer choices.
>
> -Alex
>
> On 5/30/19, 1:34 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi,
>
> @Alex Harui <ah...@adobe.com> I think you misunderstood me. I'm not
> saying
> we should "remove choices". What I say is that we have finally a more
> robust implementation and we can evolve to have more choices from that
> point. I think continue from that safe point will give us many
> benefits. So
> I want those choices. What I don't want is to wait to make it perfect
> to
> merge. As I said before perfection is enemy of the progress.
>
> An important point I can't agree with you: Why we don't use Vector in
> our
> production App? Cause we can't. To do that we need: a) Greg changes
> merged,
> b) make AMF understand Vectors (still to be done to make Vector usable
> for
> us). Without both points Vectors are not an option for us. So I think
> the
> premise of "we have 2 apps in production without Vectors" are not
> right. We
> don't have still Jewel DataGrid, or Swiz Global Dispatcher, and that
> does
> not mean it's ok for us. Is just we still don't have it, but making us
> to
> make our product without all of that is a serious issue that we need to
> workaround in some way. But we can do that as something "temporal",
> due to
> current Royale limitations. But our goal is to have all that,
> Vector-AMF
> included :)
>
> For this reason, I prefer to have Greg's Vector now, since it makes our
> production App be one step closer to remove current workarounds :)
> And I'm sure that not having a Vector solution like this, could be a
> reason
> why some people still didn't try Royale to migrate to this date.
> So if you ask me or those people for a "priority path", we will say
> "let's
> get Vector first, then evolve from that to have more choices".
> That's what I'm saying it's ok to merge now.
>
> I'm ok with having Vector as we all know it from AS3 (since is
> that...AS3
> Vector, don't forget that, and is what people expect to have at first
> sight, then we can give them more choices and they will appreciate for
> sure), and have as well a new Typed Array too as other proposed too.
> That
> will be for me options. But we should not wait to make all that happen
> to
> merge current branch, right?, All that we'll be lots of time to make it
> perfect from day 0.
>
> The key concept for me was what Harbs said in his response to the end.
> If
> you don't use it the impact is 0, not 2-3k, since people don't have
> Vector
> presence in their codes. So that's PAYG. For that reason it's ok for
> me to
> merge and continue from that safe point, since we really only get
> positive
> things and nothing negative, and since we all agree in the same terms,
> just
> we need more time to continue evolving it to get to that perfect final
> point.
>
>
>
>
> El jue., 30 may. 2019 a las 7:56, Greg Dove (<gr...@gmail.com>)
> escribió:
>
> > Harbs some quick comments inline...
> >
> > On Thu, May 30, 2019 at 4:27 PM Harbs <ha...@gmail.com> wrote:
> >
> > > The only niggle I have with my approach is that Vector in Flash is
> more
> > > performant than array, while in JS, it’s going to be the other way
> > around.
> > > So if someone has a performance-sensitive piece of code, how
> should they
> > > write it so it outputs as performant as possible on both platforms?
> > >
> > > Vector in flash is only substantially faster for its 3 numeric
> types
> > which
> > are optimized. It is (slightly) slower than Array in other cases - I
> think
> > it is normal that the extra type checking takes time even in native
> code.
> > I remember seeing some data which said it was 30% slower for some
> methods
> > with the non-primitive types, but that may be old.
> >
> > In terms of the emulation version, you can get javascript Array
> speed with
> > the index access and assignment, which should be a direct copy of
> the same
> > parts of code that are heavily optimized in flash I think.
> >
> > I was running performance tests on the non-debug flash player
> alongside
> > javascript. I actually see the regular native javascript Array
> beating
> > flash numeric Vectors in Chrome on windows, for the same tasks.
> Perhaps the
> > pepper plugin is getting less cpu resource than the browser or
> something
> > like that, not sure. I had assumed TypedArrays would be faster, but
> > recently you said you weren't sure because of js engine smarts. I
> will
> > still check that.
> >
> >
> >
> > > I have not spent the time looking into the implementation, but I
> think
> > > there might be some cross-communication. My understanding from
> what Greg
> > > wrote is that if Vector is not used in an application, there will
> be no
> > > extra code due to dead code removal. If that’s correct, I think
> we’re in
> > > agreement that the implementation is fine. Do I understand
> correctly?
> > >
> >
> > That is correct.
> >
> >
> > >
> > > Harbs
> > >
> > > > On May 30, 2019, at 1:26 AM, Josh Tynjala <
> joshtynjala@apache.org>
> > > wrote:
> > > >
> > > > I definitely want the default choice to have as few surprises as
> > > possible when it comes to how ActionScript behaves in Royale.
> We'll never
> > > have a perfect emulation, of course, but there are things that I
> think
> > can
> > > still be improved. At the same time, I think it's perfectly valid
> for
> > > someone to want to opt into a typed Array that doesn't have the
> runtime
> > > overhead of Vector and isn't as heavy in file size. I'm wary of the
> > > solution being a custom implementation of Vector with missing
> features,
> > > though. It will lead to confusion, even if it's opt-in.
> > > >
> > > > What Harbs suggested seems like a smart way to go. Rather than
> having a
> > > separate Vector implementation that doesn't work as developers are
> used
> > to,
> > > a new variation of Array that has compile-time type checks but no
> runtime
> > > checks sounds like a more elegant solution. Like Vector works in
> Royale
> > > today, it can compile down to a regular JS Array, but at
> compile-time,
> > we'd
> > > have some extra safety and could even possibly cast back and forth
> with
> > > untyped Arrays (which we can't do with Vector).
> > > >
> > > > - Josh
> > > >
> > > > On 2019/05/29 18:07:31, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> > > >> We must not eliminate choices.
> > > >>
> > > >> I still haven't had time to look at the branch.
> > > >>
> > > >> There must be away to avoid even a 1K cost to those who don't
> need it.
> > > >>
> > > >> If there is such a way, then it is fine to merge. Otherwise,
> everyone
> > > is going to pay 2K to use a Vector when we know at least two apps
> are in
> > > production without needing that 2k.
> > > >>
> > > >> There are too many words being written and no technical points
> being
> > > made. I will try to resummarize.
> > > >>
> > > >> 1) It does not matter how fast your network is. Every other
> app will
> > > use more bandwidth and when the network gets busy or connectivity
> gets
> > poor
> > > (something I see quite frequently where I live) either you get
> your app
> > to
> > > run or you run out of time.
> > > >>
> > > >> 2) If you are not using some feature of our code, you should
> not have
> > > to pay for it in download cost. That's PAYG. That would be true
> for
> > > Vector, XML and even if we had to write a Date implementation. It
> is not
> > > an issue of non-conforming. It is an issue of optimization. If
> you
> > aren't
> > > going to use some feature of E4x you should have the option of
> using code
> > > that doesn't have those code paths. Same for if we had to do Date.
> > > >>
> > > >> We know that if you don't need runtime-type checking and
> fixed-length
> > > checking that a plain Array is just fine and 2K cheaper. Let's
> give
> > folks
> > > the option to do that.
> > > >>
> > > >> I will repeat that I do not have any objection to having a full
> Vector
> > > implementation with runtime type-checking and fixed length
> checking be
> > the
> > > default choice as long as folks can optimize back to using the
> plain
> > Array
> > > code we use now.
> > > >>
> > > >> For the one Vector we currently have in all apps for the
> Strand, it
> > > might be time to change that to an array and check the type (in
> > debug-only
> > > code) on addBead. Either that or we add compiler options so that
> one
> > > Vector gets optimized to the current plain Array code.
> > > >>
> > > >> It is not a technical argument to classify Vector as "Language"
> and
> > > therefore somehow an exception to being optimizable.
> > > >>
> > > >> My 2 cents,
> > > >> -Alex
> > > >>
> > > >>
> > > >> On 5/28/19, 2:59 AM, "Carlos Rovira" <ca...@apache.org>
> > wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> I think that we all agree in most of the things, and
> although we're
> > > >> discussing some particularities on how to solve, my opinion
> is that
> > > those
> > > >> particularities can be solved after merging Language
> improvements
> > > branch.
> > > >> We all agree we need this Vector (and other improvements in
> this
> > > branch)?.
> > > >> So, after that merge folks wanting to improve, let's say,
> > Vector(for
> > > >> example) even more with new choices can do that without
> problem and
> > > will
> > > >> make it even better.
> > > >>
> > > >> Are we ok with that?
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> El mar., 28 may. 2019 a las 11:07, Harbs (<
> harbs.lists@gmail.com>)
> > > escribió:
> > > >>
> > > >>>
> > > >>>> On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com>
> > wrote:
> > > >>>>
> > > >>>>> "I personally have never used length checking in Vector. Nor
> was
> > > runtime
> > > >>>>> type checking on Vectors important to me. "
> > > >>>> length checking is automatic in flash. I don't know that you
> 'use'
> > > it...
> > > >>> it
> > > >>>> is just there.
> > > >>>
> > > >>> True. What I meant is that I never used fixed length Vectors.
> > > >>>
> > > >>>> In javascript I expect it would most often be switched off in
> all
> > > release
> > > >>>> builds, but having it on by default provides another check of
> > > something
> > > >>>> that could provide a vital clue to help people figuring out
> problems
> > > in
> > > >>>> code.
> > > >>>> So far each 'stronger typing' feature added in the last few
> months
> > has
> > > >>>> revealed potential issues or - most often - bad code that was
> > working
> > > >>> when
> > > >>>> it should not
> > > >>>
> > > >>> Good points, and one that argues for the ability to have these
> checks
> > > >>> while debugging and have the run-time code removed on release.
> > > >>>
> > > >>>> One thing about the mxml stuff is that it gets processed in a
> way
> > > that is
> > > >>>> untyped.
> > > >>>
> > > >>>
> > > >>> Agree. I do wish there was some way for MXML to be output
> “better”
> > > where
> > > >>> minified vars could “just work” and types could be better
> inferred
> > > from the
> > > >>> MXML files.
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Carlos Rovira
> > > >>
> > >
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cce57a3320feb49da636d08d6e4d9a71d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948020835204701&sdata=4u4%2FZXFJMhdghUaW9itlH89m6HGPhe34pSHdrECJnT8%3D&reserved=0
> > > >>
> > > >>
> > > >>
> > >
> > >
> >
>
>
> --
> Carlos Rovira
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cce57a3320feb49da636d08d6e4d9a71d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948020835204701&sdata=4u4%2FZXFJMhdghUaW9itlH89m6HGPhe34pSHdrECJnT8%3D&reserved=0
>
>
>
Re: Language improvements
Posted by Harbs <ha...@gmail.com>.
To me there are (or rather will be) two kinds of “Vector”.
1. `Vector.<Foo>` (which has the extra code)
2. `Foo[]` which would have no extra code.
Do you have a reason why you’d want to use `Vector.<Foo>` rather than `Foo[]`? Having two completely different constructs seems like it would be much less confusing for users.
Harbs
> On May 30, 2019, at 9:36 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> It is pretty simple to me. The proposed Vector implementation is heavy enough that we all agree that we don't want to use it for just one use case in the Strand. And so we will stop using Vector and migrate to using a plain Array. That agreement proves that the proposed changes are not right. We will effectively encourage others to do the same.
>
> It would be much better if Royale had a way for developers to specify that the one use of Vector in the Strand should be converted to plain Array by the compiler and other uses could use the proposed Vector. That's how optimization should be made available for all kinds of code in Royale, not just for Vector.
>
> The current Vector output in the develop branch is low cost and fully functional for some uses cases. As long as that output is still available as a compiler option then having other output fine.
>
> I still haven't found time to look at the actual proposed changes, but I would strongly prefer that, instead of having to modify compiler output each time someone proposes a different Vector implementation, that the changes can all be done by which SWC you choose for your Vector implementation. There are other places in the compiler where you can choose the class to use for Binding or ClassFactory. Hopefully the same approach is being used for Vector. Ideally, the compile would just output "new whateverclasstheconfigordirectivespecified()" and then just output the usual push/pop/index calls and so it could just be plain Array where specified or the proposed Vector and some other Vector someday.
>
> This is a case were "there is no one right way". And when we have those situations, we must offer choices.
>
> -Alex
>
> On 5/30/19, 1:34 AM, "Carlos Rovira" <carlosrovira@apache.org <ma...@apache.org>> wrote:
>
> Hi,
>
> @Alex Harui <ah...@adobe.com> I think you misunderstood me. I'm not saying
> we should "remove choices". What I say is that we have finally a more
> robust implementation and we can evolve to have more choices from that
> point. I think continue from that safe point will give us many benefits. So
> I want those choices. What I don't want is to wait to make it perfect to
> merge. As I said before perfection is enemy of the progress.
>
> An important point I can't agree with you: Why we don't use Vector in our
> production App? Cause we can't. To do that we need: a) Greg changes merged,
> b) make AMF understand Vectors (still to be done to make Vector usable for
> us). Without both points Vectors are not an option for us. So I think the
> premise of "we have 2 apps in production without Vectors" are not right. We
> don't have still Jewel DataGrid, or Swiz Global Dispatcher, and that does
> not mean it's ok for us. Is just we still don't have it, but making us to
> make our product without all of that is a serious issue that we need to
> workaround in some way. But we can do that as something "temporal", due to
> current Royale limitations. But our goal is to have all that, Vector-AMF
> included :)
>
> For this reason, I prefer to have Greg's Vector now, since it makes our
> production App be one step closer to remove current workarounds :)
> And I'm sure that not having a Vector solution like this, could be a reason
> why some people still didn't try Royale to migrate to this date.
> So if you ask me or those people for a "priority path", we will say "let's
> get Vector first, then evolve from that to have more choices".
> That's what I'm saying it's ok to merge now.
>
> I'm ok with having Vector as we all know it from AS3 (since is that...AS3
> Vector, don't forget that, and is what people expect to have at first
> sight, then we can give them more choices and they will appreciate for
> sure), and have as well a new Typed Array too as other proposed too. That
> will be for me options. But we should not wait to make all that happen to
> merge current branch, right?, All that we'll be lots of time to make it
> perfect from day 0.
>
> The key concept for me was what Harbs said in his response to the end. If
> you don't use it the impact is 0, not 2-3k, since people don't have Vector
> presence in their codes. So that's PAYG. For that reason it's ok for me to
> merge and continue from that safe point, since we really only get positive
> things and nothing negative, and since we all agree in the same terms, just
> we need more time to continue evolving it to get to that perfect final
> point.
>
>
>
>
> El jue., 30 may. 2019 a las 7:56, Greg Dove (<gr...@gmail.com>)
> escribió:
>
>> Harbs some quick comments inline...
>>
>> On Thu, May 30, 2019 at 4:27 PM Harbs <ha...@gmail.com> wrote:
>>
>>> The only niggle I have with my approach is that Vector in Flash is more
>>> performant than array, while in JS, it’s going to be the other way
>> around.
>>> So if someone has a performance-sensitive piece of code, how should they
>>> write it so it outputs as performant as possible on both platforms?
>>>
>>> Vector in flash is only substantially faster for its 3 numeric types
>> which
>> are optimized. It is (slightly) slower than Array in other cases - I think
>> it is normal that the extra type checking takes time even in native code.
>> I remember seeing some data which said it was 30% slower for some methods
>> with the non-primitive types, but that may be old.
>>
>> In terms of the emulation version, you can get javascript Array speed with
>> the index access and assignment, which should be a direct copy of the same
>> parts of code that are heavily optimized in flash I think.
>>
>> I was running performance tests on the non-debug flash player alongside
>> javascript. I actually see the regular native javascript Array beating
>> flash numeric Vectors in Chrome on windows, for the same tasks. Perhaps the
>> pepper plugin is getting less cpu resource than the browser or something
>> like that, not sure. I had assumed TypedArrays would be faster, but
>> recently you said you weren't sure because of js engine smarts. I will
>> still check that.
>>
>>
>>
>>> I have not spent the time looking into the implementation, but I think
>>> there might be some cross-communication. My understanding from what Greg
>>> wrote is that if Vector is not used in an application, there will be no
>>> extra code due to dead code removal. If that’s correct, I think we’re in
>>> agreement that the implementation is fine. Do I understand correctly?
>>>
>>
>> That is correct.
>>
>>
>>>
>>> Harbs
>>>
>>>> On May 30, 2019, at 1:26 AM, Josh Tynjala <jo...@apache.org>
>>> wrote:
>>>>
>>>> I definitely want the default choice to have as few surprises as
>>> possible when it comes to how ActionScript behaves in Royale. We'll never
>>> have a perfect emulation, of course, but there are things that I think
>> can
>>> still be improved. At the same time, I think it's perfectly valid for
>>> someone to want to opt into a typed Array that doesn't have the runtime
>>> overhead of Vector and isn't as heavy in file size. I'm wary of the
>>> solution being a custom implementation of Vector with missing features,
>>> though. It will lead to confusion, even if it's opt-in.
>>>>
>>>> What Harbs suggested seems like a smart way to go. Rather than having a
>>> separate Vector implementation that doesn't work as developers are used
>> to,
>>> a new variation of Array that has compile-time type checks but no runtime
>>> checks sounds like a more elegant solution. Like Vector works in Royale
>>> today, it can compile down to a regular JS Array, but at compile-time,
>> we'd
>>> have some extra safety and could even possibly cast back and forth with
>>> untyped Arrays (which we can't do with Vector).
>>>>
>>>> - Josh
>>>>
>>>> On 2019/05/29 18:07:31, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>>>> We must not eliminate choices.
>>>>>
>>>>> I still haven't had time to look at the branch.
>>>>>
>>>>> There must be away to avoid even a 1K cost to those who don't need it.
>>>>>
>>>>> If there is such a way, then it is fine to merge. Otherwise, everyone
>>> is going to pay 2K to use a Vector when we know at least two apps are in
>>> production without needing that 2k.
>>>>>
>>>>> There are too many words being written and no technical points being
>>> made. I will try to resummarize.
>>>>>
>>>>> 1) It does not matter how fast your network is. Every other app will
>>> use more bandwidth and when the network gets busy or connectivity gets
>> poor
>>> (something I see quite frequently where I live) either you get your app
>> to
>>> run or you run out of time.
>>>>>
>>>>> 2) If you are not using some feature of our code, you should not have
>>> to pay for it in download cost. That's PAYG. That would be true for
>>> Vector, XML and even if we had to write a Date implementation. It is not
>>> an issue of non-conforming. It is an issue of optimization. If you
>> aren't
>>> going to use some feature of E4x you should have the option of using code
>>> that doesn't have those code paths. Same for if we had to do Date.
>>>>>
>>>>> We know that if you don't need runtime-type checking and fixed-length
>>> checking that a plain Array is just fine and 2K cheaper. Let's give
>> folks
>>> the option to do that.
>>>>>
>>>>> I will repeat that I do not have any objection to having a full Vector
>>> implementation with runtime type-checking and fixed length checking be
>> the
>>> default choice as long as folks can optimize back to using the plain
>> Array
>>> code we use now.
>>>>>
>>>>> For the one Vector we currently have in all apps for the Strand, it
>>> might be time to change that to an array and check the type (in
>> debug-only
>>> code) on addBead. Either that or we add compiler options so that one
>>> Vector gets optimized to the current plain Array code.
>>>>>
>>>>> It is not a technical argument to classify Vector as "Language" and
>>> therefore somehow an exception to being optimizable.
>>>>>
>>>>> My 2 cents,
>>>>> -Alex
>>>>>
>>>>>
>>>>> On 5/28/19, 2:59 AM, "Carlos Rovira" <ca...@apache.org>
>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I think that we all agree in most of the things, and although we're
>>>>> discussing some particularities on how to solve, my opinion is that
>>> those
>>>>> particularities can be solved after merging Language improvements
>>> branch.
>>>>> We all agree we need this Vector (and other improvements in this
>>> branch)?.
>>>>> So, after that merge folks wanting to improve, let's say,
>> Vector(for
>>>>> example) even more with new choices can do that without problem and
>>> will
>>>>> make it even better.
>>>>>
>>>>> Are we ok with that?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> El mar., 28 may. 2019 a las 11:07, Harbs (<ha...@gmail.com>)
>>> escribió:
>>>>>
>>>>>>
>>>>>>> On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com>
>> wrote:
>>>>>>>
>>>>>>>> "I personally have never used length checking in Vector. Nor was
>>> runtime
>>>>>>>> type checking on Vectors important to me. "
>>>>>>> length checking is automatic in flash. I don't know that you 'use'
>>> it...
>>>>>> it
>>>>>>> is just there.
>>>>>>
>>>>>> True. What I meant is that I never used fixed length Vectors.
>>>>>>
>>>>>>> In javascript I expect it would most often be switched off in all
>>> release
>>>>>>> builds, but having it on by default provides another check of
>>> something
>>>>>>> that could provide a vital clue to help people figuring out problems
>>> in
>>>>>>> code.
>>>>>>> So far each 'stronger typing' feature added in the last few months
>> has
>>>>>>> revealed potential issues or - most often - bad code that was
>> working
>>>>>> when
>>>>>>> it should not
>>>>>>
>>>>>> Good points, and one that argues for the ability to have these checks
>>>>>> while debugging and have the run-time code removed on release.
>>>>>>
>>>>>>> One thing about the mxml stuff is that it gets processed in a way
>>> that is
>>>>>>> untyped.
>>>>>>
>>>>>>
>>>>>> Agree. I do wish there was some way for MXML to be output “better”
>>> where
>>>>>> minified vars could “just work” and types could be better inferred
>>> from the
>>>>>> MXML files.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>>
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cce57a3320feb49da636d08d6e4d9a71d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948020835204701&sdata=4u4%2FZXFJMhdghUaW9itlH89m6HGPhe34pSHdrECJnT8%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cce57a3320feb49da636d08d6e4d9a71d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948020835204701&sdata=4u4%2FZXFJMhdghUaW9itlH89m6HGPhe34pSHdrECJnT8%3D&reserved=0>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>
> --
> Carlos Rovira
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cce57a3320feb49da636d08d6e4d9a71d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948020835204701&sdata=4u4%2FZXFJMhdghUaW9itlH89m6HGPhe34pSHdrECJnT8%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cce57a3320feb49da636d08d6e4d9a71d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948020835204701&sdata=4u4%2FZXFJMhdghUaW9itlH89m6HGPhe34pSHdrECJnT8%3D&reserved=0>
Re: Language improvements
Posted by Alex Harui <ah...@adobe.com.INVALID>.
It is pretty simple to me. The proposed Vector implementation is heavy enough that we all agree that we don't want to use it for just one use case in the Strand. And so we will stop using Vector and migrate to using a plain Array. That agreement proves that the proposed changes are not right. We will effectively encourage others to do the same.
It would be much better if Royale had a way for developers to specify that the one use of Vector in the Strand should be converted to plain Array by the compiler and other uses could use the proposed Vector. That's how optimization should be made available for all kinds of code in Royale, not just for Vector.
The current Vector output in the develop branch is low cost and fully functional for some uses cases. As long as that output is still available as a compiler option then having other output fine.
I still haven't found time to look at the actual proposed changes, but I would strongly prefer that, instead of having to modify compiler output each time someone proposes a different Vector implementation, that the changes can all be done by which SWC you choose for your Vector implementation. There are other places in the compiler where you can choose the class to use for Binding or ClassFactory. Hopefully the same approach is being used for Vector. Ideally, the compile would just output "new whateverclasstheconfigordirectivespecified()" and then just output the usual push/pop/index calls and so it could just be plain Array where specified or the proposed Vector and some other Vector someday.
This is a case were "there is no one right way". And when we have those situations, we must offer choices.
-Alex
On 5/30/19, 1:34 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi,
@Alex Harui <ah...@adobe.com> I think you misunderstood me. I'm not saying
we should "remove choices". What I say is that we have finally a more
robust implementation and we can evolve to have more choices from that
point. I think continue from that safe point will give us many benefits. So
I want those choices. What I don't want is to wait to make it perfect to
merge. As I said before perfection is enemy of the progress.
An important point I can't agree with you: Why we don't use Vector in our
production App? Cause we can't. To do that we need: a) Greg changes merged,
b) make AMF understand Vectors (still to be done to make Vector usable for
us). Without both points Vectors are not an option for us. So I think the
premise of "we have 2 apps in production without Vectors" are not right. We
don't have still Jewel DataGrid, or Swiz Global Dispatcher, and that does
not mean it's ok for us. Is just we still don't have it, but making us to
make our product without all of that is a serious issue that we need to
workaround in some way. But we can do that as something "temporal", due to
current Royale limitations. But our goal is to have all that, Vector-AMF
included :)
For this reason, I prefer to have Greg's Vector now, since it makes our
production App be one step closer to remove current workarounds :)
And I'm sure that not having a Vector solution like this, could be a reason
why some people still didn't try Royale to migrate to this date.
So if you ask me or those people for a "priority path", we will say "let's
get Vector first, then evolve from that to have more choices".
That's what I'm saying it's ok to merge now.
I'm ok with having Vector as we all know it from AS3 (since is that...AS3
Vector, don't forget that, and is what people expect to have at first
sight, then we can give them more choices and they will appreciate for
sure), and have as well a new Typed Array too as other proposed too. That
will be for me options. But we should not wait to make all that happen to
merge current branch, right?, All that we'll be lots of time to make it
perfect from day 0.
The key concept for me was what Harbs said in his response to the end. If
you don't use it the impact is 0, not 2-3k, since people don't have Vector
presence in their codes. So that's PAYG. For that reason it's ok for me to
merge and continue from that safe point, since we really only get positive
things and nothing negative, and since we all agree in the same terms, just
we need more time to continue evolving it to get to that perfect final
point.
El jue., 30 may. 2019 a las 7:56, Greg Dove (<gr...@gmail.com>)
escribió:
> Harbs some quick comments inline...
>
> On Thu, May 30, 2019 at 4:27 PM Harbs <ha...@gmail.com> wrote:
>
> > The only niggle I have with my approach is that Vector in Flash is more
> > performant than array, while in JS, it’s going to be the other way
> around.
> > So if someone has a performance-sensitive piece of code, how should they
> > write it so it outputs as performant as possible on both platforms?
> >
> > Vector in flash is only substantially faster for its 3 numeric types
> which
> are optimized. It is (slightly) slower than Array in other cases - I think
> it is normal that the extra type checking takes time even in native code.
> I remember seeing some data which said it was 30% slower for some methods
> with the non-primitive types, but that may be old.
>
> In terms of the emulation version, you can get javascript Array speed with
> the index access and assignment, which should be a direct copy of the same
> parts of code that are heavily optimized in flash I think.
>
> I was running performance tests on the non-debug flash player alongside
> javascript. I actually see the regular native javascript Array beating
> flash numeric Vectors in Chrome on windows, for the same tasks. Perhaps the
> pepper plugin is getting less cpu resource than the browser or something
> like that, not sure. I had assumed TypedArrays would be faster, but
> recently you said you weren't sure because of js engine smarts. I will
> still check that.
>
>
>
> > I have not spent the time looking into the implementation, but I think
> > there might be some cross-communication. My understanding from what Greg
> > wrote is that if Vector is not used in an application, there will be no
> > extra code due to dead code removal. If that’s correct, I think we’re in
> > agreement that the implementation is fine. Do I understand correctly?
> >
>
> That is correct.
>
>
> >
> > Harbs
> >
> > > On May 30, 2019, at 1:26 AM, Josh Tynjala <jo...@apache.org>
> > wrote:
> > >
> > > I definitely want the default choice to have as few surprises as
> > possible when it comes to how ActionScript behaves in Royale. We'll never
> > have a perfect emulation, of course, but there are things that I think
> can
> > still be improved. At the same time, I think it's perfectly valid for
> > someone to want to opt into a typed Array that doesn't have the runtime
> > overhead of Vector and isn't as heavy in file size. I'm wary of the
> > solution being a custom implementation of Vector with missing features,
> > though. It will lead to confusion, even if it's opt-in.
> > >
> > > What Harbs suggested seems like a smart way to go. Rather than having a
> > separate Vector implementation that doesn't work as developers are used
> to,
> > a new variation of Array that has compile-time type checks but no runtime
> > checks sounds like a more elegant solution. Like Vector works in Royale
> > today, it can compile down to a regular JS Array, but at compile-time,
> we'd
> > have some extra safety and could even possibly cast back and forth with
> > untyped Arrays (which we can't do with Vector).
> > >
> > > - Josh
> > >
> > > On 2019/05/29 18:07:31, Alex Harui <ah...@adobe.com.INVALID> wrote:
> > >> We must not eliminate choices.
> > >>
> > >> I still haven't had time to look at the branch.
> > >>
> > >> There must be away to avoid even a 1K cost to those who don't need it.
> > >>
> > >> If there is such a way, then it is fine to merge. Otherwise, everyone
> > is going to pay 2K to use a Vector when we know at least two apps are in
> > production without needing that 2k.
> > >>
> > >> There are too many words being written and no technical points being
> > made. I will try to resummarize.
> > >>
> > >> 1) It does not matter how fast your network is. Every other app will
> > use more bandwidth and when the network gets busy or connectivity gets
> poor
> > (something I see quite frequently where I live) either you get your app
> to
> > run or you run out of time.
> > >>
> > >> 2) If you are not using some feature of our code, you should not have
> > to pay for it in download cost. That's PAYG. That would be true for
> > Vector, XML and even if we had to write a Date implementation. It is not
> > an issue of non-conforming. It is an issue of optimization. If you
> aren't
> > going to use some feature of E4x you should have the option of using code
> > that doesn't have those code paths. Same for if we had to do Date.
> > >>
> > >> We know that if you don't need runtime-type checking and fixed-length
> > checking that a plain Array is just fine and 2K cheaper. Let's give
> folks
> > the option to do that.
> > >>
> > >> I will repeat that I do not have any objection to having a full Vector
> > implementation with runtime type-checking and fixed length checking be
> the
> > default choice as long as folks can optimize back to using the plain
> Array
> > code we use now.
> > >>
> > >> For the one Vector we currently have in all apps for the Strand, it
> > might be time to change that to an array and check the type (in
> debug-only
> > code) on addBead. Either that or we add compiler options so that one
> > Vector gets optimized to the current plain Array code.
> > >>
> > >> It is not a technical argument to classify Vector as "Language" and
> > therefore somehow an exception to being optimizable.
> > >>
> > >> My 2 cents,
> > >> -Alex
> > >>
> > >>
> > >> On 5/28/19, 2:59 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I think that we all agree in most of the things, and although we're
> > >> discussing some particularities on how to solve, my opinion is that
> > those
> > >> particularities can be solved after merging Language improvements
> > branch.
> > >> We all agree we need this Vector (and other improvements in this
> > branch)?.
> > >> So, after that merge folks wanting to improve, let's say,
> Vector(for
> > >> example) even more with new choices can do that without problem and
> > will
> > >> make it even better.
> > >>
> > >> Are we ok with that?
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> El mar., 28 may. 2019 a las 11:07, Harbs (<ha...@gmail.com>)
> > escribió:
> > >>
> > >>>
> > >>>> On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com>
> wrote:
> > >>>>
> > >>>>> "I personally have never used length checking in Vector. Nor was
> > runtime
> > >>>>> type checking on Vectors important to me. "
> > >>>> length checking is automatic in flash. I don't know that you 'use'
> > it...
> > >>> it
> > >>>> is just there.
> > >>>
> > >>> True. What I meant is that I never used fixed length Vectors.
> > >>>
> > >>>> In javascript I expect it would most often be switched off in all
> > release
> > >>>> builds, but having it on by default provides another check of
> > something
> > >>>> that could provide a vital clue to help people figuring out problems
> > in
> > >>>> code.
> > >>>> So far each 'stronger typing' feature added in the last few months
> has
> > >>>> revealed potential issues or - most often - bad code that was
> working
> > >>> when
> > >>>> it should not
> > >>>
> > >>> Good points, and one that argues for the ability to have these checks
> > >>> while debugging and have the run-time code removed on release.
> > >>>
> > >>>> One thing about the mxml stuff is that it gets processed in a way
> > that is
> > >>>> untyped.
> > >>>
> > >>>
> > >>> Agree. I do wish there was some way for MXML to be output “better”
> > where
> > >>> minified vars could “just work” and types could be better inferred
> > from the
> > >>> MXML files.
> > >>
> > >>
> > >>
> > >> --
> > >> Carlos Rovira
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cce57a3320feb49da636d08d6e4d9a71d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948020835204701&sdata=4u4%2FZXFJMhdghUaW9itlH89m6HGPhe34pSHdrECJnT8%3D&reserved=0
> > >>
> > >>
> > >>
> >
> >
>
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cce57a3320feb49da636d08d6e4d9a71d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948020835204701&sdata=4u4%2FZXFJMhdghUaW9itlH89m6HGPhe34pSHdrECJnT8%3D&reserved=0
Re: Language improvements
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
@Alex Harui <ah...@adobe.com> I think you misunderstood me. I'm not saying
we should "remove choices". What I say is that we have finally a more
robust implementation and we can evolve to have more choices from that
point. I think continue from that safe point will give us many benefits. So
I want those choices. What I don't want is to wait to make it perfect to
merge. As I said before perfection is enemy of the progress.
An important point I can't agree with you: Why we don't use Vector in our
production App? Cause we can't. To do that we need: a) Greg changes merged,
b) make AMF understand Vectors (still to be done to make Vector usable for
us). Without both points Vectors are not an option for us. So I think the
premise of "we have 2 apps in production without Vectors" are not right. We
don't have still Jewel DataGrid, or Swiz Global Dispatcher, and that does
not mean it's ok for us. Is just we still don't have it, but making us to
make our product without all of that is a serious issue that we need to
workaround in some way. But we can do that as something "temporal", due to
current Royale limitations. But our goal is to have all that, Vector-AMF
included :)
For this reason, I prefer to have Greg's Vector now, since it makes our
production App be one step closer to remove current workarounds :)
And I'm sure that not having a Vector solution like this, could be a reason
why some people still didn't try Royale to migrate to this date.
So if you ask me or those people for a "priority path", we will say "let's
get Vector first, then evolve from that to have more choices".
That's what I'm saying it's ok to merge now.
I'm ok with having Vector as we all know it from AS3 (since is that...AS3
Vector, don't forget that, and is what people expect to have at first
sight, then we can give them more choices and they will appreciate for
sure), and have as well a new Typed Array too as other proposed too. That
will be for me options. But we should not wait to make all that happen to
merge current branch, right?, All that we'll be lots of time to make it
perfect from day 0.
The key concept for me was what Harbs said in his response to the end. If
you don't use it the impact is 0, not 2-3k, since people don't have Vector
presence in their codes. So that's PAYG. For that reason it's ok for me to
merge and continue from that safe point, since we really only get positive
things and nothing negative, and since we all agree in the same terms, just
we need more time to continue evolving it to get to that perfect final
point.
El jue., 30 may. 2019 a las 7:56, Greg Dove (<gr...@gmail.com>)
escribió:
> Harbs some quick comments inline...
>
> On Thu, May 30, 2019 at 4:27 PM Harbs <ha...@gmail.com> wrote:
>
> > The only niggle I have with my approach is that Vector in Flash is more
> > performant than array, while in JS, it’s going to be the other way
> around.
> > So if someone has a performance-sensitive piece of code, how should they
> > write it so it outputs as performant as possible on both platforms?
> >
> > Vector in flash is only substantially faster for its 3 numeric types
> which
> are optimized. It is (slightly) slower than Array in other cases - I think
> it is normal that the extra type checking takes time even in native code.
> I remember seeing some data which said it was 30% slower for some methods
> with the non-primitive types, but that may be old.
>
> In terms of the emulation version, you can get javascript Array speed with
> the index access and assignment, which should be a direct copy of the same
> parts of code that are heavily optimized in flash I think.
>
> I was running performance tests on the non-debug flash player alongside
> javascript. I actually see the regular native javascript Array beating
> flash numeric Vectors in Chrome on windows, for the same tasks. Perhaps the
> pepper plugin is getting less cpu resource than the browser or something
> like that, not sure. I had assumed TypedArrays would be faster, but
> recently you said you weren't sure because of js engine smarts. I will
> still check that.
>
>
>
> > I have not spent the time looking into the implementation, but I think
> > there might be some cross-communication. My understanding from what Greg
> > wrote is that if Vector is not used in an application, there will be no
> > extra code due to dead code removal. If that’s correct, I think we’re in
> > agreement that the implementation is fine. Do I understand correctly?
> >
>
> That is correct.
>
>
> >
> > Harbs
> >
> > > On May 30, 2019, at 1:26 AM, Josh Tynjala <jo...@apache.org>
> > wrote:
> > >
> > > I definitely want the default choice to have as few surprises as
> > possible when it comes to how ActionScript behaves in Royale. We'll never
> > have a perfect emulation, of course, but there are things that I think
> can
> > still be improved. At the same time, I think it's perfectly valid for
> > someone to want to opt into a typed Array that doesn't have the runtime
> > overhead of Vector and isn't as heavy in file size. I'm wary of the
> > solution being a custom implementation of Vector with missing features,
> > though. It will lead to confusion, even if it's opt-in.
> > >
> > > What Harbs suggested seems like a smart way to go. Rather than having a
> > separate Vector implementation that doesn't work as developers are used
> to,
> > a new variation of Array that has compile-time type checks but no runtime
> > checks sounds like a more elegant solution. Like Vector works in Royale
> > today, it can compile down to a regular JS Array, but at compile-time,
> we'd
> > have some extra safety and could even possibly cast back and forth with
> > untyped Arrays (which we can't do with Vector).
> > >
> > > - Josh
> > >
> > > On 2019/05/29 18:07:31, Alex Harui <ah...@adobe.com.INVALID> wrote:
> > >> We must not eliminate choices.
> > >>
> > >> I still haven't had time to look at the branch.
> > >>
> > >> There must be away to avoid even a 1K cost to those who don't need it.
> > >>
> > >> If there is such a way, then it is fine to merge. Otherwise, everyone
> > is going to pay 2K to use a Vector when we know at least two apps are in
> > production without needing that 2k.
> > >>
> > >> There are too many words being written and no technical points being
> > made. I will try to resummarize.
> > >>
> > >> 1) It does not matter how fast your network is. Every other app will
> > use more bandwidth and when the network gets busy or connectivity gets
> poor
> > (something I see quite frequently where I live) either you get your app
> to
> > run or you run out of time.
> > >>
> > >> 2) If you are not using some feature of our code, you should not have
> > to pay for it in download cost. That's PAYG. That would be true for
> > Vector, XML and even if we had to write a Date implementation. It is not
> > an issue of non-conforming. It is an issue of optimization. If you
> aren't
> > going to use some feature of E4x you should have the option of using code
> > that doesn't have those code paths. Same for if we had to do Date.
> > >>
> > >> We know that if you don't need runtime-type checking and fixed-length
> > checking that a plain Array is just fine and 2K cheaper. Let's give
> folks
> > the option to do that.
> > >>
> > >> I will repeat that I do not have any objection to having a full Vector
> > implementation with runtime type-checking and fixed length checking be
> the
> > default choice as long as folks can optimize back to using the plain
> Array
> > code we use now.
> > >>
> > >> For the one Vector we currently have in all apps for the Strand, it
> > might be time to change that to an array and check the type (in
> debug-only
> > code) on addBead. Either that or we add compiler options so that one
> > Vector gets optimized to the current plain Array code.
> > >>
> > >> It is not a technical argument to classify Vector as "Language" and
> > therefore somehow an exception to being optimizable.
> > >>
> > >> My 2 cents,
> > >> -Alex
> > >>
> > >>
> > >> On 5/28/19, 2:59 AM, "Carlos Rovira" <ca...@apache.org>
> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I think that we all agree in most of the things, and although we're
> > >> discussing some particularities on how to solve, my opinion is that
> > those
> > >> particularities can be solved after merging Language improvements
> > branch.
> > >> We all agree we need this Vector (and other improvements in this
> > branch)?.
> > >> So, after that merge folks wanting to improve, let's say,
> Vector(for
> > >> example) even more with new choices can do that without problem and
> > will
> > >> make it even better.
> > >>
> > >> Are we ok with that?
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> El mar., 28 may. 2019 a las 11:07, Harbs (<ha...@gmail.com>)
> > escribió:
> > >>
> > >>>
> > >>>> On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com>
> wrote:
> > >>>>
> > >>>>> "I personally have never used length checking in Vector. Nor was
> > runtime
> > >>>>> type checking on Vectors important to me. "
> > >>>> length checking is automatic in flash. I don't know that you 'use'
> > it...
> > >>> it
> > >>>> is just there.
> > >>>
> > >>> True. What I meant is that I never used fixed length Vectors.
> > >>>
> > >>>> In javascript I expect it would most often be switched off in all
> > release
> > >>>> builds, but having it on by default provides another check of
> > something
> > >>>> that could provide a vital clue to help people figuring out problems
> > in
> > >>>> code.
> > >>>> So far each 'stronger typing' feature added in the last few months
> has
> > >>>> revealed potential issues or - most often - bad code that was
> working
> > >>> when
> > >>>> it should not
> > >>>
> > >>> Good points, and one that argues for the ability to have these checks
> > >>> while debugging and have the run-time code removed on release.
> > >>>
> > >>>> One thing about the mxml stuff is that it gets processed in a way
> > that is
> > >>>> untyped.
> > >>>
> > >>>
> > >>> Agree. I do wish there was some way for MXML to be output “better”
> > where
> > >>> minified vars could “just work” and types could be better inferred
> > from the
> > >>> MXML files.
> > >>
> > >>
> > >>
> > >> --
> > >> Carlos Rovira
> > >>
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce8d86e6cf4aa4271e8ad08d6e35326eb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636946343611259722&sdata=g8BXA5jwwT98fAbwdMR2FqmJ3CgKd01zsm1lpt5pTDg%3D&reserved=0
> > >>
> > >>
> > >>
> >
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
Harbs some quick comments inline...
On Thu, May 30, 2019 at 4:27 PM Harbs <ha...@gmail.com> wrote:
> The only niggle I have with my approach is that Vector in Flash is more
> performant than array, while in JS, it’s going to be the other way around.
> So if someone has a performance-sensitive piece of code, how should they
> write it so it outputs as performant as possible on both platforms?
>
> Vector in flash is only substantially faster for its 3 numeric types which
are optimized. It is (slightly) slower than Array in other cases - I think
it is normal that the extra type checking takes time even in native code.
I remember seeing some data which said it was 30% slower for some methods
with the non-primitive types, but that may be old.
In terms of the emulation version, you can get javascript Array speed with
the index access and assignment, which should be a direct copy of the same
parts of code that are heavily optimized in flash I think.
I was running performance tests on the non-debug flash player alongside
javascript. I actually see the regular native javascript Array beating
flash numeric Vectors in Chrome on windows, for the same tasks. Perhaps the
pepper plugin is getting less cpu resource than the browser or something
like that, not sure. I had assumed TypedArrays would be faster, but
recently you said you weren't sure because of js engine smarts. I will
still check that.
> I have not spent the time looking into the implementation, but I think
> there might be some cross-communication. My understanding from what Greg
> wrote is that if Vector is not used in an application, there will be no
> extra code due to dead code removal. If that’s correct, I think we’re in
> agreement that the implementation is fine. Do I understand correctly?
>
That is correct.
>
> Harbs
>
> > On May 30, 2019, at 1:26 AM, Josh Tynjala <jo...@apache.org>
> wrote:
> >
> > I definitely want the default choice to have as few surprises as
> possible when it comes to how ActionScript behaves in Royale. We'll never
> have a perfect emulation, of course, but there are things that I think can
> still be improved. At the same time, I think it's perfectly valid for
> someone to want to opt into a typed Array that doesn't have the runtime
> overhead of Vector and isn't as heavy in file size. I'm wary of the
> solution being a custom implementation of Vector with missing features,
> though. It will lead to confusion, even if it's opt-in.
> >
> > What Harbs suggested seems like a smart way to go. Rather than having a
> separate Vector implementation that doesn't work as developers are used to,
> a new variation of Array that has compile-time type checks but no runtime
> checks sounds like a more elegant solution. Like Vector works in Royale
> today, it can compile down to a regular JS Array, but at compile-time, we'd
> have some extra safety and could even possibly cast back and forth with
> untyped Arrays (which we can't do with Vector).
> >
> > - Josh
> >
> > On 2019/05/29 18:07:31, Alex Harui <ah...@adobe.com.INVALID> wrote:
> >> We must not eliminate choices.
> >>
> >> I still haven't had time to look at the branch.
> >>
> >> There must be away to avoid even a 1K cost to those who don't need it.
> >>
> >> If there is such a way, then it is fine to merge. Otherwise, everyone
> is going to pay 2K to use a Vector when we know at least two apps are in
> production without needing that 2k.
> >>
> >> There are too many words being written and no technical points being
> made. I will try to resummarize.
> >>
> >> 1) It does not matter how fast your network is. Every other app will
> use more bandwidth and when the network gets busy or connectivity gets poor
> (something I see quite frequently where I live) either you get your app to
> run or you run out of time.
> >>
> >> 2) If you are not using some feature of our code, you should not have
> to pay for it in download cost. That's PAYG. That would be true for
> Vector, XML and even if we had to write a Date implementation. It is not
> an issue of non-conforming. It is an issue of optimization. If you aren't
> going to use some feature of E4x you should have the option of using code
> that doesn't have those code paths. Same for if we had to do Date.
> >>
> >> We know that if you don't need runtime-type checking and fixed-length
> checking that a plain Array is just fine and 2K cheaper. Let's give folks
> the option to do that.
> >>
> >> I will repeat that I do not have any objection to having a full Vector
> implementation with runtime type-checking and fixed length checking be the
> default choice as long as folks can optimize back to using the plain Array
> code we use now.
> >>
> >> For the one Vector we currently have in all apps for the Strand, it
> might be time to change that to an array and check the type (in debug-only
> code) on addBead. Either that or we add compiler options so that one
> Vector gets optimized to the current plain Array code.
> >>
> >> It is not a technical argument to classify Vector as "Language" and
> therefore somehow an exception to being optimizable.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >>
> >> On 5/28/19, 2:59 AM, "Carlos Rovira" <ca...@apache.org> wrote:
> >>
> >> Hi,
> >>
> >> I think that we all agree in most of the things, and although we're
> >> discussing some particularities on how to solve, my opinion is that
> those
> >> particularities can be solved after merging Language improvements
> branch.
> >> We all agree we need this Vector (and other improvements in this
> branch)?.
> >> So, after that merge folks wanting to improve, let's say, Vector(for
> >> example) even more with new choices can do that without problem and
> will
> >> make it even better.
> >>
> >> Are we ok with that?
> >>
> >>
> >>
> >>
> >>
> >> El mar., 28 may. 2019 a las 11:07, Harbs (<ha...@gmail.com>)
> escribió:
> >>
> >>>
> >>>> On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com> wrote:
> >>>>
> >>>>> "I personally have never used length checking in Vector. Nor was
> runtime
> >>>>> type checking on Vectors important to me. "
> >>>> length checking is automatic in flash. I don't know that you 'use'
> it...
> >>> it
> >>>> is just there.
> >>>
> >>> True. What I meant is that I never used fixed length Vectors.
> >>>
> >>>> In javascript I expect it would most often be switched off in all
> release
> >>>> builds, but having it on by default provides another check of
> something
> >>>> that could provide a vital clue to help people figuring out problems
> in
> >>>> code.
> >>>> So far each 'stronger typing' feature added in the last few months has
> >>>> revealed potential issues or - most often - bad code that was working
> >>> when
> >>>> it should not
> >>>
> >>> Good points, and one that argues for the ability to have these checks
> >>> while debugging and have the run-time code removed on release.
> >>>
> >>>> One thing about the mxml stuff is that it gets processed in a way
> that is
> >>>> untyped.
> >>>
> >>>
> >>> Agree. I do wish there was some way for MXML to be output “better”
> where
> >>> minified vars could “just work” and types could be better inferred
> from the
> >>> MXML files.
> >>
> >>
> >>
> >> --
> >> Carlos Rovira
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce8d86e6cf4aa4271e8ad08d6e35326eb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636946343611259722&sdata=g8BXA5jwwT98fAbwdMR2FqmJ3CgKd01zsm1lpt5pTDg%3D&reserved=0
> >>
> >>
> >>
>
>
Re: Language improvements
Posted by Harbs <ha...@gmail.com>.
The only niggle I have with my approach is that Vector in Flash is more performant than array, while in JS, it’s going to be the other way around. So if someone has a performance-sensitive piece of code, how should they write it so it outputs as performant as possible on both platforms?
I have not spent the time looking into the implementation, but I think there might be some cross-communication. My understanding from what Greg wrote is that if Vector is not used in an application, there will be no extra code due to dead code removal. If that’s correct, I think we’re in agreement that the implementation is fine. Do I understand correctly?
Harbs
> On May 30, 2019, at 1:26 AM, Josh Tynjala <jo...@apache.org> wrote:
>
> I definitely want the default choice to have as few surprises as possible when it comes to how ActionScript behaves in Royale. We'll never have a perfect emulation, of course, but there are things that I think can still be improved. At the same time, I think it's perfectly valid for someone to want to opt into a typed Array that doesn't have the runtime overhead of Vector and isn't as heavy in file size. I'm wary of the solution being a custom implementation of Vector with missing features, though. It will lead to confusion, even if it's opt-in.
>
> What Harbs suggested seems like a smart way to go. Rather than having a separate Vector implementation that doesn't work as developers are used to, a new variation of Array that has compile-time type checks but no runtime checks sounds like a more elegant solution. Like Vector works in Royale today, it can compile down to a regular JS Array, but at compile-time, we'd have some extra safety and could even possibly cast back and forth with untyped Arrays (which we can't do with Vector).
>
> - Josh
>
> On 2019/05/29 18:07:31, Alex Harui <ah...@adobe.com.INVALID> wrote:
>> We must not eliminate choices.
>>
>> I still haven't had time to look at the branch.
>>
>> There must be away to avoid even a 1K cost to those who don't need it.
>>
>> If there is such a way, then it is fine to merge. Otherwise, everyone is going to pay 2K to use a Vector when we know at least two apps are in production without needing that 2k.
>>
>> There are too many words being written and no technical points being made. I will try to resummarize.
>>
>> 1) It does not matter how fast your network is. Every other app will use more bandwidth and when the network gets busy or connectivity gets poor (something I see quite frequently where I live) either you get your app to run or you run out of time.
>>
>> 2) If you are not using some feature of our code, you should not have to pay for it in download cost. That's PAYG. That would be true for Vector, XML and even if we had to write a Date implementation. It is not an issue of non-conforming. It is an issue of optimization. If you aren't going to use some feature of E4x you should have the option of using code that doesn't have those code paths. Same for if we had to do Date.
>>
>> We know that if you don't need runtime-type checking and fixed-length checking that a plain Array is just fine and 2K cheaper. Let's give folks the option to do that.
>>
>> I will repeat that I do not have any objection to having a full Vector implementation with runtime type-checking and fixed length checking be the default choice as long as folks can optimize back to using the plain Array code we use now.
>>
>> For the one Vector we currently have in all apps for the Strand, it might be time to change that to an array and check the type (in debug-only code) on addBead. Either that or we add compiler options so that one Vector gets optimized to the current plain Array code.
>>
>> It is not a technical argument to classify Vector as "Language" and therefore somehow an exception to being optimizable.
>>
>> My 2 cents,
>> -Alex
>>
>>
>> On 5/28/19, 2:59 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>>
>> Hi,
>>
>> I think that we all agree in most of the things, and although we're
>> discussing some particularities on how to solve, my opinion is that those
>> particularities can be solved after merging Language improvements branch.
>> We all agree we need this Vector (and other improvements in this branch)?.
>> So, after that merge folks wanting to improve, let's say, Vector(for
>> example) even more with new choices can do that without problem and will
>> make it even better.
>>
>> Are we ok with that?
>>
>>
>>
>>
>>
>> El mar., 28 may. 2019 a las 11:07, Harbs (<ha...@gmail.com>) escribió:
>>
>>>
>>>> On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com> wrote:
>>>>
>>>>> "I personally have never used length checking in Vector. Nor was runtime
>>>>> type checking on Vectors important to me. "
>>>> length checking is automatic in flash. I don't know that you 'use' it...
>>> it
>>>> is just there.
>>>
>>> True. What I meant is that I never used fixed length Vectors.
>>>
>>>> In javascript I expect it would most often be switched off in all release
>>>> builds, but having it on by default provides another check of something
>>>> that could provide a vital clue to help people figuring out problems in
>>>> code.
>>>> So far each 'stronger typing' feature added in the last few months has
>>>> revealed potential issues or - most often - bad code that was working
>>> when
>>>> it should not
>>>
>>> Good points, and one that argues for the ability to have these checks
>>> while debugging and have the run-time code removed on release.
>>>
>>>> One thing about the mxml stuff is that it gets processed in a way that is
>>>> untyped.
>>>
>>>
>>> Agree. I do wish there was some way for MXML to be output “better” where
>>> minified vars could “just work” and types could be better inferred from the
>>> MXML files.
>>
>>
>>
>> --
>> Carlos Rovira
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce8d86e6cf4aa4271e8ad08d6e35326eb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636946343611259722&sdata=g8BXA5jwwT98fAbwdMR2FqmJ3CgKd01zsm1lpt5pTDg%3D&reserved=0
>>
>>
>>
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
The only 'safe' (for the community at large) way that I can see to do what
Alex wants is to make sure nothing of these alternate emulation classes is
*ever* baked into a swc and that the emulation variation can only be
specified for the whole build and be driven from the main application build
level.
I can think of one almost universal option for XML, which is a little more
straightforward, using dead code elimination. It might have drawbacks, but
would probably be the easiest option to implement and maintain, and I can
probably test that tomorrow with a local monkey patch.
The Vector 'emulation class' setup at the moment (which, to my knowledge,
has not been used by anyone yet) is problematic because it would end up
with the constructor variation baked into the swcs. I also think it is
cleaner and less confusing for 'alternate options' to be 'something else'
instead.
So I also agree that it would be best to add a dedicated compile-time typed
Array that is a 'new language feature' and represents something that makes
sense cross platform, something that we can specify to meet common needs.
I also think this makes sense longer term with the possible introduction of
other targets.
On Thu, May 30, 2019 at 10:26 AM Josh Tynjala <jo...@apache.org>
wrote:
> I definitely want the default choice to have as few surprises as possible
> when it comes to how ActionScript behaves in Royale. We'll never have a
> perfect emulation, of course, but there are things that I think can still
> be improved. At the same time, I think it's perfectly valid for someone to
> want to opt into a typed Array that doesn't have the runtime overhead of
> Vector and isn't as heavy in file size. I'm wary of the solution being a
> custom implementation of Vector with missing features, though. It will lead
> to confusion, even if it's opt-in.
>
> What Harbs suggested seems like a smart way to go. Rather than having a
> separate Vector implementation that doesn't work as developers are used to,
> a new variation of Array that has compile-time type checks but no runtime
> checks sounds like a more elegant solution. Like Vector works in Royale
> today, it can compile down to a regular JS Array, but at compile-time, we'd
> have some extra safety and could even possibly cast back and forth with
> untyped Arrays (which we can't do with Vector).
>
> - Josh
>
> On 2019/05/29 18:07:31, Alex Harui <ah...@adobe.com.INVALID> wrote:
> > We must not eliminate choices.
> >
> > I still haven't had time to look at the branch.
> >
> > There must be away to avoid even a 1K cost to those who don't need it.
> >
> > If there is such a way, then it is fine to merge. Otherwise, everyone
> is going to pay 2K to use a Vector when we know at least two apps are in
> production without needing that 2k.
> >
> > There are too many words being written and no technical points being
> made. I will try to resummarize.
> >
> > 1) It does not matter how fast your network is. Every other app will
> use more bandwidth and when the network gets busy or connectivity gets poor
> (something I see quite frequently where I live) either you get your app to
> run or you run out of time.
> >
> > 2) If you are not using some feature of our code, you should not have to
> pay for it in download cost. That's PAYG. That would be true for Vector,
> XML and even if we had to write a Date implementation. It is not an issue
> of non-conforming. It is an issue of optimization. If you aren't going to
> use some feature of E4x you should have the option of using code that
> doesn't have those code paths. Same for if we had to do Date.
> >
> > We know that if you don't need runtime-type checking and fixed-length
> checking that a plain Array is just fine and 2K cheaper. Let's give folks
> the option to do that.
> >
> > I will repeat that I do not have any objection to having a full Vector
> implementation with runtime type-checking and fixed length checking be the
> default choice as long as folks can optimize back to using the plain Array
> code we use now.
> >
> > For the one Vector we currently have in all apps for the Strand, it
> might be time to change that to an array and check the type (in debug-only
> code) on addBead. Either that or we add compiler options so that one
> Vector gets optimized to the current plain Array code.
> >
> > It is not a technical argument to classify Vector as "Language" and
> therefore somehow an exception to being optimizable.
> >
> > My 2 cents,
> > -Alex
> >
> >
> > On 5/28/19, 2:59 AM, "Carlos Rovira" <ca...@apache.org> wrote:
> >
> > Hi,
> >
> > I think that we all agree in most of the things, and although we're
> > discussing some particularities on how to solve, my opinion is that
> those
> > particularities can be solved after merging Language improvements
> branch.
> > We all agree we need this Vector (and other improvements in this
> branch)?.
> > So, after that merge folks wanting to improve, let's say, Vector(for
> > example) even more with new choices can do that without problem and
> will
> > make it even better.
> >
> > Are we ok with that?
> >
> >
> >
> >
> >
> > El mar., 28 may. 2019 a las 11:07, Harbs (<ha...@gmail.com>)
> escribió:
> >
> > >
> > > > On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com>
> wrote:
> > > >
> > > >> "I personally have never used length checking in Vector. Nor
> was runtime
> > > >> type checking on Vectors important to me. "
> > > > length checking is automatic in flash. I don't know that you
> 'use' it...
> > > it
> > > > is just there.
> > >
> > > True. What I meant is that I never used fixed length Vectors.
> > >
> > > > In javascript I expect it would most often be switched off in
> all release
> > > > builds, but having it on by default provides another check of
> something
> > > > that could provide a vital clue to help people figuring out
> problems in
> > > > code.
> > > > So far each 'stronger typing' feature added in the last few
> months has
> > > > revealed potential issues or - most often - bad code that was
> working
> > > when
> > > > it should not
> > >
> > > Good points, and one that argues for the ability to have these
> checks
> > > while debugging and have the run-time code removed on release.
> > >
> > > > One thing about the mxml stuff is that it gets processed in a
> way that is
> > > > untyped.
> > >
> > >
> > > Agree. I do wish there was some way for MXML to be output “better”
> where
> > > minified vars could “just work” and types could be better inferred
> from the
> > > MXML files.
> >
> >
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce8d86e6cf4aa4271e8ad08d6e35326eb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636946343611259722&sdata=g8BXA5jwwT98fAbwdMR2FqmJ3CgKd01zsm1lpt5pTDg%3D&reserved=0
> >
> >
> >
>
Re: Language improvements
Posted by Josh Tynjala <jo...@apache.org>.
I definitely want the default choice to have as few surprises as possible when it comes to how ActionScript behaves in Royale. We'll never have a perfect emulation, of course, but there are things that I think can still be improved. At the same time, I think it's perfectly valid for someone to want to opt into a typed Array that doesn't have the runtime overhead of Vector and isn't as heavy in file size. I'm wary of the solution being a custom implementation of Vector with missing features, though. It will lead to confusion, even if it's opt-in.
What Harbs suggested seems like a smart way to go. Rather than having a separate Vector implementation that doesn't work as developers are used to, a new variation of Array that has compile-time type checks but no runtime checks sounds like a more elegant solution. Like Vector works in Royale today, it can compile down to a regular JS Array, but at compile-time, we'd have some extra safety and could even possibly cast back and forth with untyped Arrays (which we can't do with Vector).
- Josh
On 2019/05/29 18:07:31, Alex Harui <ah...@adobe.com.INVALID> wrote:
> We must not eliminate choices.
>
> I still haven't had time to look at the branch.
>
> There must be away to avoid even a 1K cost to those who don't need it.
>
> If there is such a way, then it is fine to merge. Otherwise, everyone is going to pay 2K to use a Vector when we know at least two apps are in production without needing that 2k.
>
> There are too many words being written and no technical points being made. I will try to resummarize.
>
> 1) It does not matter how fast your network is. Every other app will use more bandwidth and when the network gets busy or connectivity gets poor (something I see quite frequently where I live) either you get your app to run or you run out of time.
>
> 2) If you are not using some feature of our code, you should not have to pay for it in download cost. That's PAYG. That would be true for Vector, XML and even if we had to write a Date implementation. It is not an issue of non-conforming. It is an issue of optimization. If you aren't going to use some feature of E4x you should have the option of using code that doesn't have those code paths. Same for if we had to do Date.
>
> We know that if you don't need runtime-type checking and fixed-length checking that a plain Array is just fine and 2K cheaper. Let's give folks the option to do that.
>
> I will repeat that I do not have any objection to having a full Vector implementation with runtime type-checking and fixed length checking be the default choice as long as folks can optimize back to using the plain Array code we use now.
>
> For the one Vector we currently have in all apps for the Strand, it might be time to change that to an array and check the type (in debug-only code) on addBead. Either that or we add compiler options so that one Vector gets optimized to the current plain Array code.
>
> It is not a technical argument to classify Vector as "Language" and therefore somehow an exception to being optimizable.
>
> My 2 cents,
> -Alex
>
>
> On 5/28/19, 2:59 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi,
>
> I think that we all agree in most of the things, and although we're
> discussing some particularities on how to solve, my opinion is that those
> particularities can be solved after merging Language improvements branch.
> We all agree we need this Vector (and other improvements in this branch)?.
> So, after that merge folks wanting to improve, let's say, Vector(for
> example) even more with new choices can do that without problem and will
> make it even better.
>
> Are we ok with that?
>
>
>
>
>
> El mar., 28 may. 2019 a las 11:07, Harbs (<ha...@gmail.com>) escribió:
>
> >
> > > On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com> wrote:
> > >
> > >> "I personally have never used length checking in Vector. Nor was runtime
> > >> type checking on Vectors important to me. "
> > > length checking is automatic in flash. I don't know that you 'use' it...
> > it
> > > is just there.
> >
> > True. What I meant is that I never used fixed length Vectors.
> >
> > > In javascript I expect it would most often be switched off in all release
> > > builds, but having it on by default provides another check of something
> > > that could provide a vital clue to help people figuring out problems in
> > > code.
> > > So far each 'stronger typing' feature added in the last few months has
> > > revealed potential issues or - most often - bad code that was working
> > when
> > > it should not
> >
> > Good points, and one that argues for the ability to have these checks
> > while debugging and have the run-time code removed on release.
> >
> > > One thing about the mxml stuff is that it gets processed in a way that is
> > > untyped.
> >
> >
> > Agree. I do wish there was some way for MXML to be output “better” where
> > minified vars could “just work” and types could be better inferred from the
> > MXML files.
>
>
>
> --
> Carlos Rovira
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce8d86e6cf4aa4271e8ad08d6e35326eb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636946343611259722&sdata=g8BXA5jwwT98fAbwdMR2FqmJ3CgKd01zsm1lpt5pTDg%3D&reserved=0
>
>
>
Re: Language improvements
Posted by Alex Harui <ah...@adobe.com.INVALID>.
We must not eliminate choices.
I still haven't had time to look at the branch.
There must be away to avoid even a 1K cost to those who don't need it.
If there is such a way, then it is fine to merge. Otherwise, everyone is going to pay 2K to use a Vector when we know at least two apps are in production without needing that 2k.
There are too many words being written and no technical points being made. I will try to resummarize.
1) It does not matter how fast your network is. Every other app will use more bandwidth and when the network gets busy or connectivity gets poor (something I see quite frequently where I live) either you get your app to run or you run out of time.
2) If you are not using some feature of our code, you should not have to pay for it in download cost. That's PAYG. That would be true for Vector, XML and even if we had to write a Date implementation. It is not an issue of non-conforming. It is an issue of optimization. If you aren't going to use some feature of E4x you should have the option of using code that doesn't have those code paths. Same for if we had to do Date.
We know that if you don't need runtime-type checking and fixed-length checking that a plain Array is just fine and 2K cheaper. Let's give folks the option to do that.
I will repeat that I do not have any objection to having a full Vector implementation with runtime type-checking and fixed length checking be the default choice as long as folks can optimize back to using the plain Array code we use now.
For the one Vector we currently have in all apps for the Strand, it might be time to change that to an array and check the type (in debug-only code) on addBead. Either that or we add compiler options so that one Vector gets optimized to the current plain Array code.
It is not a technical argument to classify Vector as "Language" and therefore somehow an exception to being optimizable.
My 2 cents,
-Alex
On 5/28/19, 2:59 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi,
I think that we all agree in most of the things, and although we're
discussing some particularities on how to solve, my opinion is that those
particularities can be solved after merging Language improvements branch.
We all agree we need this Vector (and other improvements in this branch)?.
So, after that merge folks wanting to improve, let's say, Vector(for
example) even more with new choices can do that without problem and will
make it even better.
Are we ok with that?
El mar., 28 may. 2019 a las 11:07, Harbs (<ha...@gmail.com>) escribió:
>
> > On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com> wrote:
> >
> >> "I personally have never used length checking in Vector. Nor was runtime
> >> type checking on Vectors important to me. "
> > length checking is automatic in flash. I don't know that you 'use' it...
> it
> > is just there.
>
> True. What I meant is that I never used fixed length Vectors.
>
> > In javascript I expect it would most often be switched off in all release
> > builds, but having it on by default provides another check of something
> > that could provide a vital clue to help people figuring out problems in
> > code.
> > So far each 'stronger typing' feature added in the last few months has
> > revealed potential issues or - most often - bad code that was working
> when
> > it should not
>
> Good points, and one that argues for the ability to have these checks
> while debugging and have the run-time code removed on release.
>
> > One thing about the mxml stuff is that it gets processed in a way that is
> > untyped.
>
>
> Agree. I do wish there was some way for MXML to be output “better” where
> minified vars could “just work” and types could be better inferred from the
> MXML files.
--
Carlos Rovira
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce8d86e6cf4aa4271e8ad08d6e35326eb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636946343611259722&sdata=g8BXA5jwwT98fAbwdMR2FqmJ3CgKd01zsm1lpt5pTDg%3D&reserved=0
Re: Language improvements
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
I think that we all agree in most of the things, and although we're
discussing some particularities on how to solve, my opinion is that those
particularities can be solved after merging Language improvements branch.
We all agree we need this Vector (and other improvements in this branch)?.
So, after that merge folks wanting to improve, let's say, Vector(for
example) even more with new choices can do that without problem and will
make it even better.
Are we ok with that?
El mar., 28 may. 2019 a las 11:07, Harbs (<ha...@gmail.com>) escribió:
>
> > On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com> wrote:
> >
> >> "I personally have never used length checking in Vector. Nor was runtime
> >> type checking on Vectors important to me. "
> > length checking is automatic in flash. I don't know that you 'use' it...
> it
> > is just there.
>
> True. What I meant is that I never used fixed length Vectors.
>
> > In javascript I expect it would most often be switched off in all release
> > builds, but having it on by default provides another check of something
> > that could provide a vital clue to help people figuring out problems in
> > code.
> > So far each 'stronger typing' feature added in the last few months has
> > revealed potential issues or - most often - bad code that was working
> when
> > it should not
>
> Good points, and one that argues for the ability to have these checks
> while debugging and have the run-time code removed on release.
>
> > One thing about the mxml stuff is that it gets processed in a way that is
> > untyped.
>
>
> Agree. I do wish there was some way for MXML to be output “better” where
> minified vars could “just work” and types could be better inferred from the
> MXML files.
--
Carlos Rovira
http://about.me/carlosrovira
Re: Language improvements
Posted by Harbs <ha...@gmail.com>.
> On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com> wrote:
>
>> "I personally have never used length checking in Vector. Nor was runtime
>> type checking on Vectors important to me. "
> length checking is automatic in flash. I don't know that you 'use' it... it
> is just there.
True. What I meant is that I never used fixed length Vectors.
> In javascript I expect it would most often be switched off in all release
> builds, but having it on by default provides another check of something
> that could provide a vital clue to help people figuring out problems in
> code.
> So far each 'stronger typing' feature added in the last few months has
> revealed potential issues or - most often - bad code that was working when
> it should not
Good points, and one that argues for the ability to have these checks while debugging and have the run-time code removed on release.
> One thing about the mxml stuff is that it gets processed in a way that is
> untyped.
Agree. I do wish there was some way for MXML to be output “better” where minified vars could “just work” and types could be better inferred from the MXML files.
Re: Language improvements
Posted by Harbs <ha...@gmail.com>.
I should have documented the problems at the time. I don’t remember the details. :-(
I’m pretty sure it related to the fact that I wanted arrays to be strongly typed, but the signatures of where the arrays were coming from were just arrays. You can’t just assign arrays (or parts of arrays) to Vectors. Some of the issues might have been from arrays which originate in web apis too.
Sorry for being so vague…
Harbs
> On May 28, 2019, at 11:12 AM, Greg Dove <gr...@gmail.com> wrote:
>
> "When I was porting a javascript library for use with Royale, array
> incompatibility with Vector was a pain point. "
> In what way? I'd be keen to understand more what the issues were.
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
"The reason I mentioned my desire to have `int[]` and `MyFoo[]` in addition
to Vector was that I thought it might be another solution to this problem. "
I believe it is the better quality solution, yes. It is also one I would be
happy to use.
"I personally have never used length checking in Vector. Nor was runtime
type checking on Vectors important to me. "
length checking is automatic in flash. I don't know that you 'use' it... it
is just there.
In javascript I expect it would most often be switched off in all release
builds, but having it on by default provides another check of something
that could provide a vital clue to help people figuring out problems in
code.
So far each 'stronger typing' feature added in the last few months has
revealed potential issues or - most often - bad code that was working when
it should not
One thing about the mxml stuff is that it gets processed in a way that is
untyped.
"When I was porting a javascript library for use with Royale, array
incompatibility with Vector was a pain point. "
In what way? I'd be keen to understand more what the issues were.
"In short, I want the ability to type check my arrays at compile time and
have them completely compatible with generic arrays (something I’m missing
currently with Vector). I don’t want or need the extra weight.
To me, a good solution would be to have full runtime type checking in
Vector and be able to use “typed” arrays (not to be confused with
TypedArrays) to avoid the runtime weight.
I discussed in the past with Josh the concept of implementing “typed
arrays” in addition to Vectors. Maybe now would be a good time to make that
happen."
Yes this is how Haxe does it too. It would be my preferred 'solution' also
"I do like the concept of optimizing how certain vectors are output (such
as TypedArrays), but that might be something that can happen later."
I am pretty sure I could do this already in the current implementation, but
it would not fully conform because Vector allows switching back and forth
between fixed length and variable length, and I cannot magically transform
a reference to a TypedArray into a regular Array when that happens. It
would only work for numeric vectors that were instantiated with the length
defined and fixed argument as true and you can never change that. If the
instance was passed to other code that believed it was a Vector it has a
false impression of what it is.
"FWIW, most JS engines will automatically use a TypedArray under the hood
if you use an array where all the elements are integers, so there’s not
usually a practical advantage to writing that optimization explicitly. "
Yeah I have read up on the V8 stuff in particular in the past, it's
seriously helpful to all of us. But I would hope there is at least a small
advantage still because TypedArray knows its element type before anything
is added to 'infer' from and the bytes that it uses are pre-allocated. It
might be a small benefit only, but I will still at least check it out.
On Tue, May 28, 2019 at 8:56 AM Harbs <ha...@gmail.com> wrote:
> The reason I mentioned my desire to have `int[]` and `MyFoo[]` in addition
> to Vector was that I thought it might be another solution to this problem.
>
> I personally have never used length checking in Vector. Nor was runtime
> type checking on Vectors important to me.
>
> When I was porting a javascript library for use with Royale, array
> incompatibility with Vector was a pain point.
>
> In short, I want the ability to type check my arrays at compile time and
> have them completely compatible with generic arrays (something I’m missing
> currently with Vector). I don’t want or need the extra weight.
>
> To me, a good solution would be to have full runtime type checking in
> Vector and be able to use “typed” arrays (not to be confused with
> TypedArrays) to avoid the runtime weight.
>
> I discussed in the past with Josh the concept of implementing “typed
> arrays” in addition to Vectors. Maybe now would be a good time to make that
> happen.
>
> I do like the concept of optimizing how certain vectors are output (such
> as TypedArrays), but that might be something that can happen later.
>
> FWIW, most JS engines will automatically use a TypedArray under the hood
> if you use an array where all the elements are integers, so there’s not
> usually a practical advantage to writing that optimization explicitly.
>
> My $0.02,
> Harbs
>
> > On May 27, 2019, at 9:43 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > Hi Greg,
> >
> > I live outside of Seattle. I'm in my house right now, and my cellphone
> says I have a 4G connection. Many times a month, I take a ferry boat to
> Seattle. There is a point during the ride where the connectivity is poor.
> Yesterday, I was trying to get work done on the ferry and was blocked from
> doing one step in the release automation because it would not load in
> time. Many times, I'm trying to get one thing finished and get stymied by
> poor connectivity. I hear this complaint from plenty of other residents
> where I live. I want Royale to produce the app that loads when other apps
> don't. Forcing everyone to take on another 2000+ bytes is not going to
> help.
> >
> > The argument of "it is only another 1K" is what eventually caused
> UIComponent to grow to 13,000 lines and 128K Hello World. That's history.
> I do not want to repeat it.
> >
> > I still haven't had time to look at your changes or read and respond to
> all of the words you've written. Mostly for others who haven't been
> following the discussion, my reasoning is as follows:
> >
> > -Vector and XML and any other built-in for SWF that isn't in JS are not
> free. We have to write some amount of code to get them to work.
> > -Vector provides runtime type checking. Not everybody needs runtime
> type checking in production.
> > -Vector provides length checking. Not everybody needs length checking
> in production.
> > -We've already proven that by having at least two projects get into
> production without your implementation of Vector.
> > -The current compiler output for Vector for folks who don't need runtime
> checking just uses Array.
> > -Your implementation adds 2990 bytes.
> >
> > For sure, we need an implementation that does runtime type-checking and
> length checking. So, as long as folks can choose to save the 2990 bytes
> and just use the current compiler output for Array in production, then we
> have given folks the right choices. Bonus if we can let folks choose other
> Vector implementations just like they can choose other XML
> implementations. My understanding from the words you've written is that
> you want everyone to use your Vector implementation and have options on
> what code paths that implementation actually takes, but I don't understand
> why from a technical perspective.
> >
> > In fact, I was reading up on Javascript TypedArrays (because that did
> load while on the ferry) and it looks like some folks might want
> Vector.<int> to map to the appropriate TypedArray. It actually got me
> wondering if folks should be able to dictate how any particular instance of
> a Vector "optimizes".
> >
> > In sum, the download size still matters. I see it quite frequently.
> Technically, why shouldn't folks have a choice of implementations?
> >
> > -Alex
> >
> > On 5/27/19, 2:46 AM, "Greg Dove" <greg.dove@gmail.com <mailto:
> greg.dove@gmail.com>> wrote:
> >
> > Hi Alex, sorry it can take a while for me to reply at the moment...
> some
> > comments inline below...
> >
> > On Sun, May 26, 2019 at 11:10 AM Alex Harui <aharui@adobe.com.invalid
> >
> > wrote:
> >
> >> Hi Greg,
> >>
> >> Thanks for working through all of this. Better Vector handling is
> >> definitely a good thing for Royale.
> >>
> >
> > I also believe so. In terms of my motivation for doing this work... I
> > actually have no imminent need for Vector, but I wanted to do
> something
> > concrete which I think is essential for 1.0.
> > I do have my own libraries and past client work from that use Vector,
> so I
> > see benefit in knowing that it will be easy to port to Royale and work
> > without any issues if I need to do that at any point (hopefully I
> will). I
> > also got to see how Vector was treated differently/specially when
> working
> > on AMF, and realized that we had no way to support it there correctly
> > because it is 'special' also in amf, so that was another motivation
> (again,
> > not for anything I actually need at the moment for myself or anyone
> else,
> > but because it is something else that is lacking for 1.0).
> >
> > However, IMO, PAYG is more important and 3KB can be a full second or
> more
> >> on busy/slow/poor networks. As such, folks need to have choices. So as
> >> long as folks can choose Vector implementations we should be good.
> >>
> >> A couple of things here. Firstly, I really did not think I would need to
> > be this specific... but iirc it was actually 2990 bytes.
> > My first reaction to your scenario above would be: that network
> connection
> > speed is really *unusable* for anything on today's internet... and
> that is
> > a problem that should be addressed first, otherwise it does not matter
> > which development tech you plan to use, it will be a common problem,
> > royale, react... whatever.
> > I can't recall something from my last 10 years where 3KB would be
> > considered a driving force for an intervention that would
> (presumably) only
> > save a portion of that (and introduce future potential maintainability
> > risks). 3KB was less than a second on dialup over 20 years ago.
> Things have
> > changed dramatically in the last 5 years in particular. We are in a HD
> > streaming world now, with many countries supporting 4K streaming
> connection
> > speeds. And average speeds continue to grow globally at solid rates
> > year-on-year. 4G has impressive global coverage, and 5G is on the
> horizon.
> > I did mention this generally my earlier comments about bandwidth
> growth
> > outpacing growth in the size of apps. With your example are you
> > hypothesizing or do you have a real recent example in mind where this
> type
> > of thing was happening? If I was asked to classify the likelihood of
> the
> > scenario you described I would describe it as a few standard
> deviations
> > away from the center of the bell curve based on my own experience.
> >
> > However I absolutely do agree with you that choice is important, I
> just
> > believe that performance most often will be more of a reason for the
> > decision to choose alternates (and it may mean adding 'size', not
> reducing
> > it).
> > And I think the choice should be explicit/obvious rather than having
> > something that is a lesser implementation of what it is actually
> supposed
> > to be. By this, I mean more application framework alternatives,
> instead of
> > supporting variations that represent non-conforming language classes.
> If
> > that approach is used, I think it will result in clearer, better
> quality,
> > more maintainable code. This is also a general approachI have observed
> > elsewhere.
> >
> > Choosing Array is always an option in javascript and provides a zero
> > byte-weight option. I also plan to introduce some options for the
> numeric
> > types that represent best performance across both targets... but not
> as
> > 'Vector' numeric types. The aim here would be to get faster than
> 'Vector as
> > Array' in javascript and it will be just a convenience approach to
> avoid
> > writing your own COMPILE::JS blocks with the native TypedArrays.
> >
> > In terms of tweaking this Vector implementation's performance as
> further
> > options, I already explained I am happy to work on that based on
> actual
> > feedback for need. But I still think it requires caution and
> consideration
> > in terms of potential risks for people releasing libraries that could
> > expose non-conforming instances of Vectors (something that can never
> happen
> > in swf).
> > There are perhaps some possibilities for enhancing [ArrayElementType]
> with
> > a compiletime=true argument to get something more like what Harbs is
> after,
> > but that would only work for class members, not local vars. Perhaps
> there
> > are other simple ways to add 'compiletime' safety without going to
> full
> > blown generics support yet.
> >
> >
> >> Flex failed in some major vendors' customer-facing apps because of
> >> download times. I have spent the past years trying to make sure Royale
> >> does not repeat those mistakes.
> >>
> >>
> > I do want you to understand that I'm on the same team. And like you, I
> > don't want to repeat old mistakes too. But I also would like to see us
> > avoid possible new ones.
> > In the last 5 years or so, I have never really had a client spend
> much time
> > focusing on the size. Before that I think I was more aware of it.
> Anyhow,
> > it's not that it was never important at all, it's just that it was
> > relatively unimportant compared to other aspects. And apart from
> > remembering the size of flex apps in the past, I've seen the size of
> react
> > apps I worked on recently too.
> > I actually just looked at one of those. It is 8762KB minified and
> > compresses to 1293KB gzipped. The app does not compare directly, but
> it is
> > similar to Carlos' app in that it has many complex input rules and
> > sequences, however in a lot of ways Carlos' app is far more complex
> and has
> > a lot more remote API calls. However the final result from royale with
> > Carlos's app has a much, much lighter footprint than those numbers for
> > react. So Alex, I think the work you and others have put into avoiding
> > unneeded weight in the application framework has paid (and will
> continue to
> > pay) 'dividends' (as a metaphoric expression for anyone unfamiliar
> with
> > that).
> > But I do think of the language layer below the application framework
> layer
> > as 'different' and that it should be treated as if it has existing
> > specifications that are not free to reshape as we see fit (which it
> does,
> > directly or indirectly). The language is still actionscript, it's not
> > royalescript or jactionscript or something else. I've also spelt out a
> > number of the reasons why I have these views earlier. One thing I did
> not
> > mention was that my views also reflect my experience and observations
> with
> > another cross platform language. I have seen some cases, for example,
> where
> > over the course of iterative improvements, the use of native classes
> (the
> > example that springs to mind was for XML parsing) was removed from a
> > language level library and the whole feature was re-implemented in
> local
> > code because it was more desirable to achieve consistency across
> targets
> > than to have the best performing code on any one target. The IDE
> plugin for
> > that particular sdk has over 120K downloads in the one IDE I use most
> often
> > and it has a number of other IDEs supporting it with their own
> plugins etc.
> > So I have reason to believe it is popular, and I know it is
> disciplined at
> > the language level for a number of these shared target aspects. The
> > consistency therefore seems to be very important to its user base,
> more so
> > than the prospect of each language level feature 'being the smallest
> it can
> > be'. But beyond the core language it also has lots of scope for
> > accommodating differences. My exposure to this (and involvment with
> it in
> > the past) has also influenced my thinking. I try to avoid thinking
> "that's
> > them and not us" because that is a poor reason to ignore the
> learnings of
> > others. Much of my own knowledge and skills over the years is the
> result of
> > shared knowledge (royale and yourself included as a boost to that for
> which
> > I am grateful). Anyway, part of the thinking does come from awareness
> of
> > other things elsewhere, but I did pass it through my 'how does it
> relate to
> > royale' filter.
> >
> >
> > I have some comments on finer details, but let's see if we can agree
> on
> >> this higher-level issue first. We simply should offer people choices.
> >>
> >> Just repeating: I too am keen to offer choices and also to make it easy
> to
> > choose them. We only have different views over what those choices
> should
> > be. I would prefer them to be safer choices. I believe avoiding the
> > multiple Vector implementation approach will avoid future pitfalls and
> > possible developer confusion that could arise from the distribution of
> > inconsistent or non-conforming language level code. Neither of us can
> be
> > certain if those risks are real. But there is one way to avoid them
> for
> > sure (and yet still provide choices). That is essentially the crux of
> my
> > thinking. Do you think that logic is reasonable at the higher-level?
> >
> > Beyond that, I did not obviously remove any emulationClass code in the
> > compiler and would not do so without your agreement, so nothing there
> has
> > changed.
> > Actually in the branch I think I changed something to pass qualified
> name
> > instead of basename somewhere, because base name would not be correct
> in
> > the general case. For that reason I don't think anybody was using that
> > feature yet, although I know you added it in response to a request
> from
> > Joshua Granick, as a way to address the Array-not-Vector issue. I do
> not
> > think it should be there now that we have something that we can call
> our
> > own, which is why I asked if we could remove it. Anyway, in terms of
> that
> > decision, can we agree to table it for now, merge the branch and maybe
> > continue this discussion later? I will go ahead and work on the other
> > 'choices' I have in mind regardless, maybe when you see them you might
> > change how you think about things (or not, it is the apache way).
> >
> >
> >> Thanks,
> >> -Alex
> >>
> >> On 5/25/19, 2:45 PM, "Greg Dove" <gr...@gmail.com> wrote:
> >>
> >> Hi Carlos, thanks for your feedback. In terms of PAYG, I just have a
> >> sense
> >> that at the language level, the 'default' should be that it *works*
> as
> >> per
> >> design.
> >> If I take the example of Vector... then numeric Vector types will not
> >> run
> >> faster in javascript. Using all the method calls will have a
> >> substantial
> >> impact compared to using a normal Array. But code should 'work' the
> >> same
> >> across targets.
> >> I do have some ideas for application framework classes outside
> >> 'language'/Vector that would provide target-agnostic fast regular
> class
> >> implementations for numeric typed Arrays, and I hope to work on that
> >> soon
> >> as well, which takes more advantage of the optimized native options
> on
> >> each
> >> target (Vector in swf, TypedArray in javascript). But to achieve that
> >> it
> >> will likely be 'always fixed length' in this case, I will see if it
> >> seems
> >> worth trying to be able to toggle that, or maybe it can be a bead or
> >> opt-in
> >> support to get that functionality. But that should provide a good
> >> option
> >> for developers seeking to get the best performance for numeric
> >> collections.
> >> I expect to work on this during June.
> >> Or developers can of course always choose to implement their own
> custom
> >> performance code in COMPILE::JS / COMPILE::SWF variations, which is
> >> always
> >> an option.
> >>
> >>
> >> Hi Piotr, sorry about that email formatting issue. Thanks for your
> >> follow
> >> up on this.
> >> Here is a paste of that part, which includes the code.
> >>
> >>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdPWy&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=2InnN50ng8lXwYsDKMZXNiEoHCcMDutiw%2BmOAifDqdc%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdPWy&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=2InnN50ng8lXwYsDKMZXNiEoHCcMDutiw%2BmOAifDqdc%3D&reserved=0
> >
> >>
> >> Also, if you want to see the tests for Vector, you can see them 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&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sp48jNSTgvHikdp9A2d2L%2Bwkq5vcHII%2BBqD%2BiXczSaQ%3D&reserved=0
> <
> 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&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sp48jNSTgvHikdp9A2d2L%2Bwkq5vcHII%2BBqD%2BiXczSaQ%3D&reserved=0
> >
> >>
> >>
> >> You should see large parts of that series of tests fail outside the
> >> branch, and in some cases there were compiler errors too iirc (or
> >> maybe I
> >> am confusing some compiler fixes I did for other things, can't be
> sure
> >> now)
> >>
> >>
> >>
> >> On Sun, May 26, 2019 at 4:58 AM Carlos Rovira <
> carlosrovira@apache.org <ma...@apache.org>
> >>>
> >> wrote:
> >>
> >>> Hi!
> >>>
> >>> Read it! :), was long but I think this emails are needed since it
> >> brings
> >>> many thoughts that only the developer knows and otherwise would end
> >> never
> >>> known by the rest of the community. So Great!
> >>>
> >>> Greg, first, many thanks for working on this. I think we get other
> >> point
> >>> solved, and I think not only Vector, but many other fixes and things
> >> coming
> >>> in your branch.
> >>>
> >>> For my part, as you said, the branch is tested against my real
> >> project,
> >>> that I think is a very good way to test against lots of working
> >> code. So
> >>> for my is ok to merge, not only cause it does not brake anything,
> >> but cause
> >>> it's a big step forward.
> >>>
> >>> Since it brings things we didn't have before like Vector, is good to
> >> bring
> >>> this. Then we can continue iterating to add missed things like AMF
> >> support
> >>> or to evolve to other state or even change internal things if other
> >> check
> >>> and see ways of enhancements.
> >>>
> >>> About the Vector implementation. My opinion is that I think as you
> >> that
> >>> Vector is an intrinsic part of AS3, so better to have an
> >> implementation to
> >>> complete AS3 in Royale. About having multiple implementations, I
> >> think that
> >>> could be good in the future if things can be done that way, but
> >> better
> >>> start from this starting point and see what happens in next
> >> months-years.
> >>> IOW, better have a real implementation now that a potentially one
> >> that
> >>> still is not here. We need to see the goal and approach to it
> >> progressively
> >>> or we end getting nothing since the goal is a huge one not easy to
> >> reach.
> >>>
> >>> For me the 3kb is totally normal, and as well a great achievement of
> >> your
> >>> implementation.
> >>> I must say that my way of thinking in Royale is to be totally
> >> aligned with
> >>> concepts like PAYG, but sometimes we need to break rules when the
> >> goal
> >>> demand it, or we can end trying to apply the same principle to all
> >> things,
> >>> when sometimes is not the best. So this is importante, rules are
> >> really
> >>> good, but we need to always put behind a layer of human thinking
> >> about what
> >>> we are trying to accomplish
> >>>
> >>> Thanks Greg for reaching another important milestone! Amazing work!
> >> :)
> >>>
> >>> Carlos
> >>>
> >>> PD: Piotr, about gmail cutting the email, I'm using gmail and get to
> >> read
> >>> it completely, maybe could be a problem of gmail in mobile? I'm
> >> reading on
> >>> gmail desktop. The only problem I had was reading posted source
> >> code, but
> >>> since it was tiny, I could finally read it...
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> El sáb., 25 may. 2019 a las 15:37, Piotr Zarzycki (<
> >>> piotrzarzycki21@gmail.com <ma...@gmail.com>>)
> escribió:
> >>>
> >>>> Hi Greg,
> >>>>
> >>>> Could you please post the code from this email in the
> >> paste.apache.org <http://paste.apache.org/> -
> >>>> right now is unreadable in my Gmail account.
> >>>>
> >>>> Thanks,
> >>>> Piotr
> >>>>
> >>>> On Sat, May 25, 2019, 4:51 AM Greg Dove <greg.dove@gmail.com <mailto:
> greg.dove@gmail.com>>
> >> wrote:
> >>>>
> >>>>> OK, At the risk of making what follows even longer... a warning:
> >> *this
> >>>> is a
> >>>>> long read*. It might veer off topic in one or two places, but it
> >> is
> >>>> mostly
> >>>>> about why, and how Vector is implemented the way it is in the
> >> branch.
> >>>>> Basically I would like to merge this branch into develop as soon
> >> as
> >>>>> possible, i actually think it is ready as is, but I am keen to
> >> get
> >>> other
> >>>>> input before I do.
> >>>>> Read it if you're interested. If you're not interested in
> >> reading it
> >>> then
> >>>>> please try the branch on any 'real' projects that you have in
> >> play.
> >>>> Carlos
> >>>>> has tested against his, and there are no issues, but it would be
> >> good
> >>> to
> >>>>> get wider input.
> >>>>>
> >>>>> now to the textual onslaught:
> >>>>>
> >>>>>
> >>>>> *Vector*
> >>>>>
> >>>>> One of the things I did before I worked on this Vector
> >> implementation
> >>> was
> >>>>> to detach myself from ‘how I use Vector when I code’, to take a
> >> step
> >>> back
> >>>>> and challenge myself to rethink how I thought about it in
> >> general.
> >>>>>
> >>>>> Vector is *special*. Vector is not *a class* in a typical sense.
> >> It is
> >>>> the
> >>>>> closest thing that as3 has to generics which, when used at a
> >> class
> >>>> level, I
> >>>>> like to think of as the ability to generate multiple class
> >> variations
> >>>> from
> >>>>> a single class definition (that is just the way I think of
> >> them). So,
> >>> at
> >>>>> some level Vector could be considered as an infinite set of
> >> distinct
> >>>>> classes, based on an infinite set of possible specified element
> >> types
> >>>>> (whatever you see between the angle brackets in code). It is not
> >>> actually
> >>>>> implemented natively in AVM this way iiuc, but that is the
> >> outward
> >>>>> appearance, and that is also the behaviour it has when using type
> >>>> checking
> >>>>> in as3.
> >>>>>
> >>>>> Aside from the runtime typesafe behaviour, Vector’s strong
> >> typing means
> >>>>> there is additional compile time support and, related, the
> >> possibility
> >>> of
> >>>>> extra IDE support, both of which help the developer.
> >>>>>
> >>>>> Vector ‘types’ are also final ‘classes’ enforced by the
> >> compiler, so
> >>>> cannot
> >>>>> be extended.
> >>>>>
> >>>>> Additionally, on looking closer, there are some other quirky
> >> rules for
> >>>>> runtime typing behaviour. These are related to the
> >> implementation in
> >>> AVM.
> >>>>> The 3 Vector types for Vector.<int>, Vector.<uint>, and
> >> Vector.<Number>
> >>>> are
> >>>>> individual base types, and then there is a 4th base type,
> >> Vector.<*>
> >>>> which
> >>>>> serves as the ‘base class’ of all other Vector ‘subclasses’. The
> >> 3
> >>>> numeric
> >>>>> types are faster than Array, and I expect this was the reason
> >> for the
> >>>>> separation, because these are used in a lot of other flash apis,
> >>>>> particularly for swapping with byte level data and things like
> >>> BitmapData
> >>>>> etc. The others are more simply for the strong typing aspects,
> >> because
> >>>>> (perhaps less so with Boolean and String at a guess) they are
> >> somewhat
> >>>>> slower than Array in AVM, because of the overhead of runtime
> >>> typechecking
> >>>>> and coercions etc. So the main selling points for choosing a
> >> Vector in
> >>>>> flash were a) compile time and runtime type safety and b) faster
> >>>>> performance for the 3 numeric Vector types.
> >>>>>
> >>>>> One implication of these ‘rules’ means that to check if
> >> *something* is
> >>> a
> >>>>> Vector of any type in swf, I need to do (mything is Vector.<int>
> >> ||
> >>>> myThing
> >>>>> is Vector.<uint> || myThing is Vector.<Number> || myThing is
> >>> Vector.<*>)
> >>>> or
> >>>>> use reflection (which is slower).
> >>>>>
> >>>>> The above implies that, for language conformance (considered as
> >>>> conformance
> >>>>> with as3 documentation/spec and the behaviour of the reference
> >>>>> implementation that we have for any ‘unknowns’) in an emulation,
> >> a
> >>>> regular
> >>>>> single as3 class implementation would not create a result that is
> >>>>> consistent with the spec in terms of its representation of
> >> typing, and
> >>>> its
> >>>>> behaviour when using type checking.
> >>>>>
> >>>>> I tried to take all of these things into consideration.
> >>>>>
> >>>>>
> >>>>>
> >>>>> *How is it implemented in the branch?*
> >>>>>
> >>>>> Vector is implemented using the lightweight ‘synthType’ approach
> >> I
> >>> added
> >>>>> previously to support for int and uint types as ‘classes’. This
> >>> provides
> >>>> a
> >>>>> light integration for ‘is’ and ‘as’ checks, but in javascript
> >> itself a
> >>>>> Vector instance is simply a tagged native javascript Array
> >> instance
> >>> (i.e.
> >>>>> an Array with something that identifies it as being ‘not a
> >> regular
> >>>> Array’).
> >>>>> The Array methods are enhanced at the instance level to support
> >> the
> >>> type
> >>>>> coercions that take place in an actionscript Vector. Using Array
> >> makes
> >>>>> sense because Vector instances are essentially typed Arrays. But
> >> it is
> >>>> not
> >>>>> possible to extend Array in javascript and have things work
> >> properly
> >>> (it
> >>>> is
> >>>>> possible to use a different approach with es6 Proxy, but that is
> >> not
> >>>>> available in IE11).
> >>>>>
> >>>>> This implementation also means that a ‘Vector’ instance should
> >> have
> >>>>> functionality that works mostly as expected if it is passed
> >> directly to
> >>>> a 3
> >>>>> rd party native javascript library that is expecting an Array
> >> instance.
> >>>> It
> >>>>> will not support errors when changing the length if the Vector
> >> instance
> >>>> is
> >>>>> ‘fixed’ length, for example but otherwise it should function
> >> much the
> >>>> same
> >>>>> as a regular Array in the 3rd party code.
> >>>>>
> >>>>> The ‘synthType’ approach can be used because Vector types are
> >> final, so
> >>>> it
> >>>>> does not need to conform to a regular Royale class definition
> >> that can
> >>> be
> >>>>> extended and can be much ‘lighter’. As with int and uint
> >> ‘classes’, no
> >>>>> Vector constructor exists until the first one is requested.
> >> There is
> >>> one
> >>>>> internal private class in Language that provides most of the
> >>>> functionality
> >>>>> for Vector, and element coercion functions are generated
> >> specifically
> >>> for
> >>>>> each Vector ‘subtype’. Overall, it behaves more like a subclass
> >>> ‘factory’
> >>>>> with each individual type’s constructor being created on demand
> >> and
> >>>> cached
> >>>>> for future use.
> >>>>>
> >>>>> Reflection and serialization support have not been added yet,
> >> but I
> >>>>> certainly had these in mind also with this approach. I just
> >> wanted to
> >>>> reach
> >>>>> a sensible intermediate point for now, and then add those in
> >> later.
> >>>>>
> >>>>> In summary, the Vector implementation in the branch provides the
> >>>> following:
> >>>>>
> >>>>> -distinct types (conforming in terms of type checking) for each
> >> Vector
> >>>>> subtype
> >>>>>
> >>>>> -lightweight integration with Language ‘is’ and ‘as’ support
> >>>>>
> >>>>> -each Vector subtype has a unique constructor generated the
> >> first time
> >>> it
> >>>>> is requested, the constructor does not exist prior to that.
> >>>>>
> >>>>> -expected to be compatible with 3rd party native javascript that
> >>> expects
> >>>> a
> >>>>> regular javascript Array
> >>>>>
> >>>>> -serialization (amf) and reflection are not yet supported but
> >> were
> >>>>> considered, and that is planned as next steps.
> >>>>>
> >>>>> As at the time of writing, the current implementation is
> >> supported by
> >>> 300
> >>>>> Vector-specific assertions that run side-by-side between
> >> javascript and
> >>>> swf
> >>>>> in the manualtest UnitTests project. Apart from the differences
> >> created
> >>>> by
> >>>>> explicitly switching off some type safety checks with
> >>>>> @suppressvectorindexchecking, there is only one verifiable
> >> difference
> >>> in
> >>>>> these tests between swf and javsacript. Probably there are things
> >>> outside
> >>>>> the test coverage that might need addressing still, but I think
> >> it’s a
> >>>>> pretty good start.
> >>>>>
> >>>>> These tests should be easily ported to framework level unit tests
> >>>>> (RoyaleUnit) as the same approach has been used to add FlexUnit
> >> tests
> >>> in
> >>>>> the past. Testing/Development is primarily in Chrome on windows,
> >> but
> >>> the
> >>>>> same tests were subsequently verified on IE11, Edge, Opera and
> >> Firefox
> >>> on
> >>>>> windows.
> >>>>>
> >>>>> *Implementation Info*
> >>>>>
> >>>>> *More quirks*
> >>>>>
> >>>>> A ‘fixed == true’ Vector cannot have its length changed. This
> >> means
> >>> that
> >>>>> changes via the length setter and the mutation methods (push,
> >> pop,
> >>> shift,
> >>>>> unshift etc) all throw errors if used when a Vector is ‘fixed ==
> >> true’.
> >>>>> But… splice method also can change length. And in AVM this works
> >> even
> >>>> with
> >>>>> a fixed length Vector, which might possibly be a bug but is one
> >> that is
> >>>>> matched in the implementation to conform with flash.
> >>>>>
> >>>>> *Size impact.*
> >>>>>
> >>>>> Alex was concerned with size impact for HelloWorld because the
> >> beads
> >>> were
> >>>>> using a Vector.<IBead> type in javascript in one of the
> >> application
> >>>>> framework base classes. But the requirement was for that to
> >> simply to
> >>> be
> >>>> an
> >>>>> Array in javascript, the compiler was only achieving that by
> >> default
> >>>>> because there was no real Vector implementation. So I did a
> >> couple of
> >>>>> things here. Firstly I changed the application framework code to
> >>> reflect
> >>>>> the different requirement for javascript. Secondly, I added some
> >> doc
> >>>>> comment directives to suppress exporting on public members. Then
> >> I
> >>> added
> >>>>> this to the Language methods that are for compiler-generated
> >> Vector
> >>> (and
> >>>>> int and uint) support so that they are eligible for dead code
> >>> elimination
> >>>>> if not used. This effectively means that it is fully PAYG – it
> >> is only
> >>>>> there if you need it, but if you need it there is also no effort
> >> to add
> >>>> it
> >>>>> in as an optional dependency. If, because of this, there is a
> >> potential
> >>>> for
> >>>>> issues with modules or something I have not thought of, that
> >> will be
> >>>>> another thing to solve, but if so, I will find a way to address
> >> it.
> >>>>>
> >>>>> If the main concern with ‘size’ is data transfer, then looking
> >> at the
> >>>>> minified output size in HelloWorld is not really meaningful (or
> >> perhaps
> >>>> it
> >>>>> is better to say that it is only as meaningful as looking at the
> >> size
> >>> of
> >>>> an
> >>>>> uncompressed swf compared to normal deployment of a compressed
> >> swf). In
> >>>> any
> >>>>> real deployment the javascript should be served as gzipped. So I
> >>> compared
> >>>>> gzipped (‘normal’ compression) versions of HelloWorld.js between
> >> those
> >>>> with
> >>>>> the unused Language support methods (for int/uint and Vector)
> >> and their
> >>>>> dependencies vs. builds without. The support for all that
> >> functionality
> >>>>> comes in at under 3 Kb difference in the gzipped output. I
> >> personally
> >>>> don’t
> >>>>> think that would register as important in most cases. However,
> >> it is
> >>>> pretty
> >>>>> close to zero impact now if it is not used. In fact the
> >> HelloWorld
> >>>>> application is now about 55 bytes smaller than it was before, so
> >> I
> >>>> consider
> >>>>> it ‘carbon-netural’. And these are at the gzipped levels (it is
> >> also
> >>>>> slightly smaller when not gzipped, although it can sometimes be
> >> the
> >>> case
> >>>>> that the larger of 2 files compresses better than a smaller one,
> >>>> depending
> >>>>> on the content).
> >>>>>
> >>>>> As a general comment about size… in my experience over the last
> >> 10
> >>> years
> >>>> or
> >>>>> so, mostly in relation to Flex apps, size was most often not
> >> among the
> >>>>> highest priority issues. Sure, start-up time often was. But that
> >> is not
> >>>>> size per se. Often ‘size’ issues were first and foremost ‘asset
> >> size’
> >>>>> issues (embedded or separate). While I know overall that it
> >> remains
> >>>>> important, I personally think the growth in bandwidth and device
> >> memory
> >>>> in
> >>>>> general has outpaced the growth in the size of web apps even as
> >> the
> >>> world
> >>>>> has turned to mobile. In other words, I think we probably passed
> >> a
> >>> hurdle
> >>>>> point in the mobile side of things. Admittedly that is just
> >>> ‘perception’
> >>>>> and maybe there is data that shows I am quite wrong or your
> >> experience
> >>> on
> >>>>> specific client projects could be quite different. The point of
> >> me
> >>>>> explaining that was, however, to illustrate why I think ‘size’
> >> sits
> >>>> where I
> >>>>> think it does in general in terms of importance: I consider it
> >> to be
> >>>> behind
> >>>>> stability/reliability first which is followed by performance in
> >>>> performance
> >>>>> critical code. Overriding that general flow (which again, is
> >> just my
> >>>>> opinion), are whatever my client’s specific requirements are for
> >> any
> >>>>> particular project. In other words I am not sure how much of
> >>> HelloWorld’s
> >>>>> size is going to be an important deciding factor for someone to
> >> choose
> >>> to
> >>>>> use Royale. I think the ‘I got it to work!’ is the real kicker
> >> here.
> >>> This
> >>>>> paragraph was not to cause any conflict, and I already addressed
> >> the
> >>>> ‘size’
> >>>>> impact in the branch, so I’m not saying it wasn’t necessary to
> >> do that
> >>>>> (although I do suspect the same attention was not given to all
> >> other
> >>>> things
> >>>>> in the past that affected HelloWorld). It’s more to promote
> >> discussion
> >>>> and
> >>>>> thought in general. Trying to be all one aspect (small size) can
> >>>> compromise
> >>>>> other aspects (reliability or stability or compatibility, for
> >> example).
> >>>> And
> >>>>> trying to accommodate all aspects (reliability, small size,
> >> exceptional
> >>>>> performance) somehow very likely increases complexity because
> >> there is
> >>> a
> >>>>> need to accommodate the explicit decisions for trade-offs between
> >>>> competing
> >>>>> aspects. It would be good to have a guide of priorities based on
> >> the
> >>>> needs
> >>>>> of the user base (while I might have a strong opinion about what
> >> I
> >>> think
> >>>> is
> >>>>> important, I don’t assume that my views necessarily represent
> >> wider
> >>> user
> >>>>> needs, because I have not done research to support that – and
> >> it’s not
> >>>>> really a twitter poll kind of thing!). Anyhow I got off track
> >> there a
> >>>> bit…
> >>>>> back to Vector…
> >>>>>
> >>>>>
> >>>>>
> >>>>> *Performance.*
> >>>>>
> >>>>> No-one should expect a non-native Vector implementation to
> >> perform
> >>> faster
> >>>>> than native Array in javascript. Its main benefit is type
> >> safety, and
> >>>> that
> >>>>> is the reason it should be selected for use over Array. (In swf,
> >> native
> >>>>> numeric Vector types *are* selected for performance, but the
> >> other
> >>> Vector
> >>>>> types are also at least slightly slower than Array, so selecting
> >> them
> >>> is
> >>>>> based on the need for type safety)
> >>>>>
> >>>>> There are, however some ways to get 100% Array performance with
> >> this
> >>>>> implementation, and in a loop, for example it would be similar to
> >>>> avoiding
> >>>>> method calls (like push/pop) and only using index assignments
> >> that is
> >>>>> typical of performance optimization in swf.
> >>>>>
> >>>>> So these two methods provide almost Identical performance in js:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> *private function testArrayInt2(iterations:uint):Number{ var
> >>>> start:Date
> >>>>> = new Date(); var inst:Array = new Array(iterations);
> >> for
> >>>> (var
> >>>>> i:uint=0;i<iterations; i++) { inst[i] = i; }
> >> return new
> >>>>> Date().valueOf() - start.valueOf(); } /** * *
> >>>>> @royalesuppressvectorindexcheck true */ private function
> >>>>> testVectorInt2(iterations:uint):Number{ var start:Date = new
> >>> Date();
> >>>>> var inst:Vector.<uint> = new Vector.<uint>(iterations);
> >> for
> >>>>> (var i:uint=0;i<iterations; i++) { inst[i] = i; }
> >>> return
> >>>>> new Date().valueOf() - start.valueOf(); }*
> >>>>>
> >>>>> The doc comment on the 2nd method prevented the compiler from
> >>> generating
> >>>> an
> >>>>> index check wrapper around the ‘i’ in inst[i]
> >>>>>
> >>>>> The above 2 methods take around 5-7 ms for 500,000 iterations on
> >> my
> >>>> machine
> >>>>> (chrome/windows). This is quite a bit faster than the same
> >> methods in
> >>> the
> >>>>> swf (non-debug) build on my machine. The Vector constructor is
> >> also
> >>> doing
> >>>>> extra work in this case by setting all the 500,000 slots to
> >> numeric 0.
> >>>> But
> >>>>> on modern browsers it is using a fast native Array.fill method
> >> to do
> >>>> that,
> >>>>> so it’s probably more noticeable on IE11 which uses a for loop to
> >>>>> pre-populate the contents with numeric 0 values.
> >>>>>
> >>>>> For reference, the generated code for the second method above,
> >> looks
> >>> like
> >>>>> this:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> */** * * @royalesuppressvectorindexcheck true * @private *
> >> @param
> >>>>> {number} iterations * @return {number} */
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> flexUnitTests.language.LanguageTesterTestVectorPerf.prototype.flexUnitTests_language_LanguageTesterTestVectorPerf_testVectorInt2
> >>>>> = function(iterations) { var /** @type {Date} */ start = new
> >> Date();
> >>>>> var /** @type {Array.<number>} */ inst = new
> >>>>>
> >> (org.apache.royale.utils.Language.synthVector('uint'))(iterations);
> >>> for
> >>>>> (var /** @type {number} */ i = 0; i < iterations; i++) {
> >> inst[i] =
> >>> i;
> >>>>> } return new Date().valueOf() - start.valueOf(); };*
> >>>>>
> >>>>> The methods with type checking in them, like push, unshift etc
> >> will be
> >>>>> quite a lot slower though. This should not be a surprise. In
> >> swf, when
> >>>> you
> >>>>> look at something like Vector.<IBead> it can be up to 30% slower
> >> than
> >>>> Array
> >>>>> for methods like push, iirc at native level. In javascript it
> >> will be a
> >>>> lot
> >>>>> more. But in both cases it has type safety. And for small
> >> collection
> >>>> sizes
> >>>>> in non-performance sensitive code it is probably not going to
> >> make a
> >>>>> meaningul difference.
> >>>>>
> >>>>> Known limitations
> >>>>>
> >>>>> 1. myVectorInstance[‘constructor’] can be different
> >> between js
> >>> and
> >>>>> swf
> >>>>>
> >>>>> 2. There is some reliance on not obscuring the type from
> >> the
> >>>> compiler
> >>>>> for things to work correctly. Example:
> >>>>>
> >>>>> var myObscuredType:* = new Vector.<String>(20,true) // creates a
> >> fixed
> >>>>> Vector of length 20
> >>>>>
> >>>>> myObscuredType.length = 21; //should throw an error, but does
> >> not in
> >>>>> javascript.
> >>>>>
> >>>>> This will work as long as the compiler knows that the type with
> >> the
> >>>> length
> >>>>> setter is some type of Vector, otherwise not.
> >>>>>
> >>>>>
> >>>>>
> >>>>> *Performance tuning*
> >>>>>
> >>>>> *@royalesuppressvectorindexcheck*
> >>>>>
> >>>>> The above doc comment directive avoids checking for
> >> out-of-valid-range
> >>>>> index values on assignments. This is extremely desirable inside
> >> loops
> >>>> which
> >>>>> are usually constrained to the valid range in any case. There is
> >> a top
> >>>>> level compiler configuration setting for this, but local
> >> settings win
> >>>>> (turning off or on generally with true/false, or suppressing
> >>> specifically
> >>>>> for individual local variable names)
> >>>>>
> >>>>>
> >>>>>
> >>>>> Other options.
> >>>>>
> >>>>> The above one was obvious to me as an important tuning option. I
> >>> started
> >>>>> with adding another but pulled it out in favor of adding them
> >> based on
> >>>>> actual need.
> >>>>>
> >>>>> There are many options:
> >>>>>
> >>>>> Instance based: reducing type checking with a compiler-only
> >> generated
> >>>>> additional constructor parameter, triggered by some doc comment
> >>>> directive.
> >>>>> This could be in the form of adding in compiler generated
> >> alternatve
> >>>> calls
> >>>>> to things like ‘unsafePush’ and ‘unsafePop’ on instances, or
> >> perhaps
> >>>>> literal calls to Array.prototype.push.call(inst, pushItem),
> >> triggered
> >>> by
> >>>>> some doc comment directive
> >>>>>
> >>>>> Global changes:Adding some compiler define value that (along
> >> with:
> >>>>> ||goog.DEBUG) suppresses many runtime checks in the release
> >> Vector
> >>>>> implementation. This would allow a blanket approach to dialing
> >> runtime
> >>>>> safety down (or keeping them) in the release build. It would
> >> apply
> >>> across
> >>>>> all libraries and local project code.
> >>>>>
> >>>>> Some combinations of the above that allow sweeping optimizations
> >> with
> >>>> local
> >>>>> exceptions.
> >>>>>
> >>>>> Basically, this branch currently represents what I have reason to
> >>> believe
> >>>>> is a high conformance Vector implementation which should be the
> >> default
> >>>> as
> >>>>> it is an as3 core type. I think there are many options to scale
> >> things
> >>>>> back, but rather than assume what they should be, I’d prefer to
> >> hear
> >>> from
> >>>>> users and address *real* needs, so that we only end up with
> >>> configuration
> >>>>> options that matter.
> >>>>>
> >>>>>
> >>>>>
> >>>>> *Advantages of a single Vector implementation – the case for
> >> avoiding a
> >>>>> ‘vector emulation class’*
> >>>>>
> >>>>> ‘Language emulation’ is a foundational layer that is not in the
> >> same
> >>>>> category as ‘application framework’ where we can define things
> >> how we
> >>>> want.
> >>>>> Because the royale sdk includes both aspects inside ‘framework’
> >> (and
> >>> that
> >>>>> was obviously not the case for flex sdk in the past) it may be
> >> easy to
> >>>>> overlook that difference.
> >>>>>
> >>>>> Vector typing is a core part of AS3 language. Therefore it should
> >>> conform
> >>>>> and be reliable. Having multiple implementations for a core
> >> language
> >>>>> feature seems wrong and could easily lead to libraries of code
> >> that are
> >>>>> incompatible. Additionally, as pointed out earlier, Vector is
> >> more
> >>> like a
> >>>>> subclass factory (‘runtime’ generics) than a single class, so
> >> won’t be
> >>>> well
> >>>>> represented by a regular class implementation.
> >>>>>
> >>>>> Alex, I know you added support for a Vector emulation class
> >> approach to
> >>>>> meet the needs of someone asking for improved Vector support, in
> >> part
> >>>>> because we did not have someone who had volunteered to write our
> >> own. I
> >>>> did
> >>>>> that last part now. I am also suggesting that the emulation class
> >>>> approach
> >>>>> is not a good long term solution because of the above reasons.
> >> And the
> >>>> full
> >>>>> set of functionality is less than 3Kb in the gzipped output, so
> >> I’d
> >>>> suggest
> >>>>> that as long as I can add needs-based performance tuning options
> >> for
> >>>> those
> >>>>> who want them, the benefits of having a single conforming
> >>> implementation
> >>>>> which is performance scalable are better than the risks
> >> associated with
> >>>>> adding partially non-conforming ones. Therefore I’d like to ask
> >> if we
> >>> can
> >>>>> remove that functionality now that we have our own 'Vector' (I
> >> can do
> >>> the
> >>>>> work if you prefer as I know your focus is understandably on
> >> other
> >>>> things).
> >>>>>
> >>>>> *Future:*
> >>>>>
> >>>>> It will be easily possibly to alter the current implementation
> >> to use
> >>> es6
> >>>>> proxy which would likely provide the most reliable way to get
> >> full
> >>> Vector
> >>>>> conformance indistinguishable from flash. Es6 proxy is
> >> transparent for
> >>>>> Array:
> >>>>>
> >>>>> var p = new Proxy(new Array(), {});
> >>>>>
> >>>>> Array.isArray(p) // true
> >>>>>
> >>>>> This should allow trapping things like the length setter before
> >> it gets
> >>>> to
> >>>>> the underlying Array target, and doing checking for fixed ==
> >> true etc.
> >>>> The
> >>>>> same is true for numeric index-based assignment of values etc.
> >>>>>
> >>>>> es6 Proxy is kinda cool. At the moment IE11 is the only
> >> meaningful
> >>> target
> >>>>> that does not support this.
> >>>>>
> >>>>> I am only mentioning this here because I did think about this,
> >> and I
> >>>>> believe that the current implementation could be upgraded quite
> >> easily
> >>> to
> >>>>> use this approach if it makes sense (when IE11 is a distant
> >> memory –
> >>>>> perhaps sometime next year!).
> >>>>>
> >>>>>
> >>>>>
> >>>>> Phew, you made it! Well done.
> >>>>>
> >>>>> Feel free to share your thoughts or ask any questions you might
> >> have.
> >>> If
> >>>>> you have neither of those at this time, please still try to find
> >> time
> >>> to
> >>>>> test any large projects you have in the branch, and provide
> >> feedback or
> >>>>> share any concerns you might have after doing that.
> >>>>> thanks,
> >>>>> Greg
> >>>>>
> >>>>>
> >>>>> On Thu, May 23, 2019 at 7:55 PM Greg Dove <greg.dove@gmail.com
> <ma...@gmail.com>>
> >> wrote:
> >>>>>
> >>>>>> Re XMLTest manualtest...
> >>>>>>
> >>>>>> Yep those were the ones I ported, Harbs. I think I got them
> >> all but
> >>> may
> >>>>>> have missed some. I added a bunch more as well. Hopefully
> >> these can
> >>> be
> >>>>>> easily migrated to what Josh has been working on.
> >>>>>>
> >>>>>>
> >>>>>> On Thu, 23 May 2019, 19:43 Harbs, <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>>
> >> wrote:
> >>>>>>
> >>>>>>> As far as XML unit tests go, the starting point should be
> >> XMLTest in
> >>>>>>> manual tests. (Almost) every time I ran into an issue, I
> >> added it to
> >>>>> that
> >>>>>>> project.
> >>>>>>>
> >>>>>>> I think I might have been lax on the last few issues I fixed,
> >> so we
> >>>>>>> should probably go through the later XML commits and make
> >> sure we
> >>> have
> >>>>>>> tests for that.
> >>>>>>>
> >>>>>>> As far as Node goes, I think we probably need conditional Node
> >>>>>>> compilation to handle Node-specific (and browser specific)
> >> code in a
> >>>>> PAYG
> >>>>>>> way.
> >>>>>>>
> >>>>>>> To technically handle the parsing, something like
> >>>>>>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0
> >
> >> <
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0
> >
> >>>
> >>>> is
> >>>>> a
> >>>>>>> good starting point and something like this
> >>>>>>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0
> >
> >> <
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0
> >
> >>>
> >>>>>>> might be useful to either use or modify.
> >>>>>>>
> >>>>>>> Harbs
> >>>>>>>
> >>>>>>>> On May 23, 2019, at 10:18 AM, Greg Dove <
> >> greg.dove@gmail.com <ma...@gmail.com>>
> >>>> wrote:
> >>>>>>>>
> >>>>>>>> All, I started porting some adhoc XML tests to UnitTests and
> >>>>> eventually
> >>>>>>>> ended up spending quite a bit of time on addressing issues
> >> that
> >>>> arose
> >>>>>>> for
> >>>>>>>> XML before getting back to Vector stuff.
> >>>>>>>> I think XML probably needs many more unit tests before we
> >> get to
> >>> 1.0
> >>>>>>>> because it has an extensive api. I have not used royale
> >> with Node
> >>>> yet,
> >>>>>>> but
> >>>>>>>> XML also needs some thought about how to get it working on
> >> Node, I
> >>>>>>> assume.
> >>>>>>>> Because XML uses the browser's parser and Node does not
> >> have one
> >>> by
> >>>>>>>> default, then using the same code will need something to
> >> take the
> >>>>> place
> >>>>>>> of
> >>>>>>>> the browser's native parser for Node. There is a lib in npm
> >> that
> >>>> might
> >>>>>>> be
> >>>>>>>> useful for that, but I don't know how that might work with
> >> licence
> >>>>> etc.
> >>>>>>>> Anyhow, that is just an observation, I will focus on Vector
> >> in
> >>> this
> >>>>>>>> thread... I will post here late tomorrow local time with
> >> more
> >>> info,
> >>>>> and
> >>>>>>>> discussion points. I am keen to see this merged in, but
> >> also keen
> >>> to
> >>>>> get
> >>>>>>>> buy-in first.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <
> >>>>> carlosrovira@apache.org <ma...@apache.org>
> >>>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> 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.dove@gmail.com <ma...@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.dove@gmail.com <ma...@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
> >>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>
> >>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> +1 to renaming the options to the positive.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <
> >> joshtynjala@apache.org <ma...@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.dove@gmail.com <ma...@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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=vC7Sy%2BfGwJhbS8bR0Eo4wZBTNxsuEGCWXQ6nHceAk18%3D&reserved=0
> <
> 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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=vC7Sy%2BfGwJhbS8bR0Eo4wZBTNxsuEGCWXQ6nHceAk18%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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=NlTd48QGPtLVuoxX%2Fv4IO0ZZyz3CMgh7Gzllr3D%2BIoA%3D&reserved=0
> <
> 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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=NlTd48QGPtLVuoxX%2Fv4IO0ZZyz3CMgh7Gzllr3D%2BIoA%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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=dwgAt0Rz%2Bt575HRIk97kPbtewGN4mSv8FbCQr6Skudg%3D&reserved=0
> <
> 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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=dwgAt0Rz%2Bt575HRIk97kPbtewGN4mSv8FbCQr6Skudg%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
> >>>>>>>>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0
> >
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Carlos Rovira
> >>>
> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0
> >
>
Re: Language improvements
Posted by Harbs <ha...@gmail.com>.
The reason I mentioned my desire to have `int[]` and `MyFoo[]` in addition to Vector was that I thought it might be another solution to this problem.
I personally have never used length checking in Vector. Nor was runtime type checking on Vectors important to me.
When I was porting a javascript library for use with Royale, array incompatibility with Vector was a pain point.
In short, I want the ability to type check my arrays at compile time and have them completely compatible with generic arrays (something I’m missing currently with Vector). I don’t want or need the extra weight.
To me, a good solution would be to have full runtime type checking in Vector and be able to use “typed” arrays (not to be confused with TypedArrays) to avoid the runtime weight.
I discussed in the past with Josh the concept of implementing “typed arrays” in addition to Vectors. Maybe now would be a good time to make that happen.
I do like the concept of optimizing how certain vectors are output (such as TypedArrays), but that might be something that can happen later.
FWIW, most JS engines will automatically use a TypedArray under the hood if you use an array where all the elements are integers, so there’s not usually a practical advantage to writing that optimization explicitly.
My $0.02,
Harbs
> On May 27, 2019, at 9:43 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Hi Greg,
>
> I live outside of Seattle. I'm in my house right now, and my cellphone says I have a 4G connection. Many times a month, I take a ferry boat to Seattle. There is a point during the ride where the connectivity is poor. Yesterday, I was trying to get work done on the ferry and was blocked from doing one step in the release automation because it would not load in time. Many times, I'm trying to get one thing finished and get stymied by poor connectivity. I hear this complaint from plenty of other residents where I live. I want Royale to produce the app that loads when other apps don't. Forcing everyone to take on another 2000+ bytes is not going to help.
>
> The argument of "it is only another 1K" is what eventually caused UIComponent to grow to 13,000 lines and 128K Hello World. That's history. I do not want to repeat it.
>
> I still haven't had time to look at your changes or read and respond to all of the words you've written. Mostly for others who haven't been following the discussion, my reasoning is as follows:
>
> -Vector and XML and any other built-in for SWF that isn't in JS are not free. We have to write some amount of code to get them to work.
> -Vector provides runtime type checking. Not everybody needs runtime type checking in production.
> -Vector provides length checking. Not everybody needs length checking in production.
> -We've already proven that by having at least two projects get into production without your implementation of Vector.
> -The current compiler output for Vector for folks who don't need runtime checking just uses Array.
> -Your implementation adds 2990 bytes.
>
> For sure, we need an implementation that does runtime type-checking and length checking. So, as long as folks can choose to save the 2990 bytes and just use the current compiler output for Array in production, then we have given folks the right choices. Bonus if we can let folks choose other Vector implementations just like they can choose other XML implementations. My understanding from the words you've written is that you want everyone to use your Vector implementation and have options on what code paths that implementation actually takes, but I don't understand why from a technical perspective.
>
> In fact, I was reading up on Javascript TypedArrays (because that did load while on the ferry) and it looks like some folks might want Vector.<int> to map to the appropriate TypedArray. It actually got me wondering if folks should be able to dictate how any particular instance of a Vector "optimizes".
>
> In sum, the download size still matters. I see it quite frequently. Technically, why shouldn't folks have a choice of implementations?
>
> -Alex
>
> On 5/27/19, 2:46 AM, "Greg Dove" <greg.dove@gmail.com <ma...@gmail.com>> wrote:
>
> Hi Alex, sorry it can take a while for me to reply at the moment... some
> comments inline below...
>
> On Sun, May 26, 2019 at 11:10 AM Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
>> Hi Greg,
>>
>> Thanks for working through all of this. Better Vector handling is
>> definitely a good thing for Royale.
>>
>
> I also believe so. In terms of my motivation for doing this work... I
> actually have no imminent need for Vector, but I wanted to do something
> concrete which I think is essential for 1.0.
> I do have my own libraries and past client work from that use Vector, so I
> see benefit in knowing that it will be easy to port to Royale and work
> without any issues if I need to do that at any point (hopefully I will). I
> also got to see how Vector was treated differently/specially when working
> on AMF, and realized that we had no way to support it there correctly
> because it is 'special' also in amf, so that was another motivation (again,
> not for anything I actually need at the moment for myself or anyone else,
> but because it is something else that is lacking for 1.0).
>
> However, IMO, PAYG is more important and 3KB can be a full second or more
>> on busy/slow/poor networks. As such, folks need to have choices. So as
>> long as folks can choose Vector implementations we should be good.
>>
>> A couple of things here. Firstly, I really did not think I would need to
> be this specific... but iirc it was actually 2990 bytes.
> My first reaction to your scenario above would be: that network connection
> speed is really *unusable* for anything on today's internet... and that is
> a problem that should be addressed first, otherwise it does not matter
> which development tech you plan to use, it will be a common problem,
> royale, react... whatever.
> I can't recall something from my last 10 years where 3KB would be
> considered a driving force for an intervention that would (presumably) only
> save a portion of that (and introduce future potential maintainability
> risks). 3KB was less than a second on dialup over 20 years ago. Things have
> changed dramatically in the last 5 years in particular. We are in a HD
> streaming world now, with many countries supporting 4K streaming connection
> speeds. And average speeds continue to grow globally at solid rates
> year-on-year. 4G has impressive global coverage, and 5G is on the horizon.
> I did mention this generally my earlier comments about bandwidth growth
> outpacing growth in the size of apps. With your example are you
> hypothesizing or do you have a real recent example in mind where this type
> of thing was happening? If I was asked to classify the likelihood of the
> scenario you described I would describe it as a few standard deviations
> away from the center of the bell curve based on my own experience.
>
> However I absolutely do agree with you that choice is important, I just
> believe that performance most often will be more of a reason for the
> decision to choose alternates (and it may mean adding 'size', not reducing
> it).
> And I think the choice should be explicit/obvious rather than having
> something that is a lesser implementation of what it is actually supposed
> to be. By this, I mean more application framework alternatives, instead of
> supporting variations that represent non-conforming language classes. If
> that approach is used, I think it will result in clearer, better quality,
> more maintainable code. This is also a general approachI have observed
> elsewhere.
>
> Choosing Array is always an option in javascript and provides a zero
> byte-weight option. I also plan to introduce some options for the numeric
> types that represent best performance across both targets... but not as
> 'Vector' numeric types. The aim here would be to get faster than 'Vector as
> Array' in javascript and it will be just a convenience approach to avoid
> writing your own COMPILE::JS blocks with the native TypedArrays.
>
> In terms of tweaking this Vector implementation's performance as further
> options, I already explained I am happy to work on that based on actual
> feedback for need. But I still think it requires caution and consideration
> in terms of potential risks for people releasing libraries that could
> expose non-conforming instances of Vectors (something that can never happen
> in swf).
> There are perhaps some possibilities for enhancing [ArrayElementType] with
> a compiletime=true argument to get something more like what Harbs is after,
> but that would only work for class members, not local vars. Perhaps there
> are other simple ways to add 'compiletime' safety without going to full
> blown generics support yet.
>
>
>> Flex failed in some major vendors' customer-facing apps because of
>> download times. I have spent the past years trying to make sure Royale
>> does not repeat those mistakes.
>>
>>
> I do want you to understand that I'm on the same team. And like you, I
> don't want to repeat old mistakes too. But I also would like to see us
> avoid possible new ones.
> In the last 5 years or so, I have never really had a client spend much time
> focusing on the size. Before that I think I was more aware of it. Anyhow,
> it's not that it was never important at all, it's just that it was
> relatively unimportant compared to other aspects. And apart from
> remembering the size of flex apps in the past, I've seen the size of react
> apps I worked on recently too.
> I actually just looked at one of those. It is 8762KB minified and
> compresses to 1293KB gzipped. The app does not compare directly, but it is
> similar to Carlos' app in that it has many complex input rules and
> sequences, however in a lot of ways Carlos' app is far more complex and has
> a lot more remote API calls. However the final result from royale with
> Carlos's app has a much, much lighter footprint than those numbers for
> react. So Alex, I think the work you and others have put into avoiding
> unneeded weight in the application framework has paid (and will continue to
> pay) 'dividends' (as a metaphoric expression for anyone unfamiliar with
> that).
> But I do think of the language layer below the application framework layer
> as 'different' and that it should be treated as if it has existing
> specifications that are not free to reshape as we see fit (which it does,
> directly or indirectly). The language is still actionscript, it's not
> royalescript or jactionscript or something else. I've also spelt out a
> number of the reasons why I have these views earlier. One thing I did not
> mention was that my views also reflect my experience and observations with
> another cross platform language. I have seen some cases, for example, where
> over the course of iterative improvements, the use of native classes (the
> example that springs to mind was for XML parsing) was removed from a
> language level library and the whole feature was re-implemented in local
> code because it was more desirable to achieve consistency across targets
> than to have the best performing code on any one target. The IDE plugin for
> that particular sdk has over 120K downloads in the one IDE I use most often
> and it has a number of other IDEs supporting it with their own plugins etc.
> So I have reason to believe it is popular, and I know it is disciplined at
> the language level for a number of these shared target aspects. The
> consistency therefore seems to be very important to its user base, more so
> than the prospect of each language level feature 'being the smallest it can
> be'. But beyond the core language it also has lots of scope for
> accommodating differences. My exposure to this (and involvment with it in
> the past) has also influenced my thinking. I try to avoid thinking "that's
> them and not us" because that is a poor reason to ignore the learnings of
> others. Much of my own knowledge and skills over the years is the result of
> shared knowledge (royale and yourself included as a boost to that for which
> I am grateful). Anyway, part of the thinking does come from awareness of
> other things elsewhere, but I did pass it through my 'how does it relate to
> royale' filter.
>
>
> I have some comments on finer details, but let's see if we can agree on
>> this higher-level issue first. We simply should offer people choices.
>>
>> Just repeating: I too am keen to offer choices and also to make it easy to
> choose them. We only have different views over what those choices should
> be. I would prefer them to be safer choices. I believe avoiding the
> multiple Vector implementation approach will avoid future pitfalls and
> possible developer confusion that could arise from the distribution of
> inconsistent or non-conforming language level code. Neither of us can be
> certain if those risks are real. But there is one way to avoid them for
> sure (and yet still provide choices). That is essentially the crux of my
> thinking. Do you think that logic is reasonable at the higher-level?
>
> Beyond that, I did not obviously remove any emulationClass code in the
> compiler and would not do so without your agreement, so nothing there has
> changed.
> Actually in the branch I think I changed something to pass qualified name
> instead of basename somewhere, because base name would not be correct in
> the general case. For that reason I don't think anybody was using that
> feature yet, although I know you added it in response to a request from
> Joshua Granick, as a way to address the Array-not-Vector issue. I do not
> think it should be there now that we have something that we can call our
> own, which is why I asked if we could remove it. Anyway, in terms of that
> decision, can we agree to table it for now, merge the branch and maybe
> continue this discussion later? I will go ahead and work on the other
> 'choices' I have in mind regardless, maybe when you see them you might
> change how you think about things (or not, it is the apache way).
>
>
>> Thanks,
>> -Alex
>>
>> On 5/25/19, 2:45 PM, "Greg Dove" <gr...@gmail.com> wrote:
>>
>> Hi Carlos, thanks for your feedback. In terms of PAYG, I just have a
>> sense
>> that at the language level, the 'default' should be that it *works* as
>> per
>> design.
>> If I take the example of Vector... then numeric Vector types will not
>> run
>> faster in javascript. Using all the method calls will have a
>> substantial
>> impact compared to using a normal Array. But code should 'work' the
>> same
>> across targets.
>> I do have some ideas for application framework classes outside
>> 'language'/Vector that would provide target-agnostic fast regular class
>> implementations for numeric typed Arrays, and I hope to work on that
>> soon
>> as well, which takes more advantage of the optimized native options on
>> each
>> target (Vector in swf, TypedArray in javascript). But to achieve that
>> it
>> will likely be 'always fixed length' in this case, I will see if it
>> seems
>> worth trying to be able to toggle that, or maybe it can be a bead or
>> opt-in
>> support to get that functionality. But that should provide a good
>> option
>> for developers seeking to get the best performance for numeric
>> collections.
>> I expect to work on this during June.
>> Or developers can of course always choose to implement their own custom
>> performance code in COMPILE::JS / COMPILE::SWF variations, which is
>> always
>> an option.
>>
>>
>> Hi Piotr, sorry about that email formatting issue. Thanks for your
>> follow
>> up on this.
>> Here is a paste of that part, which includes the code.
>>
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdPWy&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=2InnN50ng8lXwYsDKMZXNiEoHCcMDutiw%2BmOAifDqdc%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdPWy&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=2InnN50ng8lXwYsDKMZXNiEoHCcMDutiw%2BmOAifDqdc%3D&reserved=0>
>>
>> Also, if you want to see the tests for Vector, you can see them 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&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sp48jNSTgvHikdp9A2d2L%2Bwkq5vcHII%2BBqD%2BiXczSaQ%3D&reserved=0 <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&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sp48jNSTgvHikdp9A2d2L%2Bwkq5vcHII%2BBqD%2BiXczSaQ%3D&reserved=0>
>>
>>
>> You should see large parts of that series of tests fail outside the
>> branch, and in some cases there were compiler errors too iirc (or
>> maybe I
>> am confusing some compiler fixes I did for other things, can't be sure
>> now)
>>
>>
>>
>> On Sun, May 26, 2019 at 4:58 AM Carlos Rovira <carlosrovira@apache.org <ma...@apache.org>
>>>
>> wrote:
>>
>>> Hi!
>>>
>>> Read it! :), was long but I think this emails are needed since it
>> brings
>>> many thoughts that only the developer knows and otherwise would end
>> never
>>> known by the rest of the community. So Great!
>>>
>>> Greg, first, many thanks for working on this. I think we get other
>> point
>>> solved, and I think not only Vector, but many other fixes and things
>> coming
>>> in your branch.
>>>
>>> For my part, as you said, the branch is tested against my real
>> project,
>>> that I think is a very good way to test against lots of working
>> code. So
>>> for my is ok to merge, not only cause it does not brake anything,
>> but cause
>>> it's a big step forward.
>>>
>>> Since it brings things we didn't have before like Vector, is good to
>> bring
>>> this. Then we can continue iterating to add missed things like AMF
>> support
>>> or to evolve to other state or even change internal things if other
>> check
>>> and see ways of enhancements.
>>>
>>> About the Vector implementation. My opinion is that I think as you
>> that
>>> Vector is an intrinsic part of AS3, so better to have an
>> implementation to
>>> complete AS3 in Royale. About having multiple implementations, I
>> think that
>>> could be good in the future if things can be done that way, but
>> better
>>> start from this starting point and see what happens in next
>> months-years.
>>> IOW, better have a real implementation now that a potentially one
>> that
>>> still is not here. We need to see the goal and approach to it
>> progressively
>>> or we end getting nothing since the goal is a huge one not easy to
>> reach.
>>>
>>> For me the 3kb is totally normal, and as well a great achievement of
>> your
>>> implementation.
>>> I must say that my way of thinking in Royale is to be totally
>> aligned with
>>> concepts like PAYG, but sometimes we need to break rules when the
>> goal
>>> demand it, or we can end trying to apply the same principle to all
>> things,
>>> when sometimes is not the best. So this is importante, rules are
>> really
>>> good, but we need to always put behind a layer of human thinking
>> about what
>>> we are trying to accomplish
>>>
>>> Thanks Greg for reaching another important milestone! Amazing work!
>> :)
>>>
>>> Carlos
>>>
>>> PD: Piotr, about gmail cutting the email, I'm using gmail and get to
>> read
>>> it completely, maybe could be a problem of gmail in mobile? I'm
>> reading on
>>> gmail desktop. The only problem I had was reading posted source
>> code, but
>>> since it was tiny, I could finally read it...
>>>
>>>
>>>
>>>
>>>
>>> El sáb., 25 may. 2019 a las 15:37, Piotr Zarzycki (<
>>> piotrzarzycki21@gmail.com <ma...@gmail.com>>) escribió:
>>>
>>>> Hi Greg,
>>>>
>>>> Could you please post the code from this email in the
>> paste.apache.org <http://paste.apache.org/> -
>>>> right now is unreadable in my Gmail account.
>>>>
>>>> Thanks,
>>>> Piotr
>>>>
>>>> On Sat, May 25, 2019, 4:51 AM Greg Dove <greg.dove@gmail.com <ma...@gmail.com>>
>> wrote:
>>>>
>>>>> OK, At the risk of making what follows even longer... a warning:
>> *this
>>>> is a
>>>>> long read*. It might veer off topic in one or two places, but it
>> is
>>>> mostly
>>>>> about why, and how Vector is implemented the way it is in the
>> branch.
>>>>> Basically I would like to merge this branch into develop as soon
>> as
>>>>> possible, i actually think it is ready as is, but I am keen to
>> get
>>> other
>>>>> input before I do.
>>>>> Read it if you're interested. If you're not interested in
>> reading it
>>> then
>>>>> please try the branch on any 'real' projects that you have in
>> play.
>>>> Carlos
>>>>> has tested against his, and there are no issues, but it would be
>> good
>>> to
>>>>> get wider input.
>>>>>
>>>>> now to the textual onslaught:
>>>>>
>>>>>
>>>>> *Vector*
>>>>>
>>>>> One of the things I did before I worked on this Vector
>> implementation
>>> was
>>>>> to detach myself from ‘how I use Vector when I code’, to take a
>> step
>>> back
>>>>> and challenge myself to rethink how I thought about it in
>> general.
>>>>>
>>>>> Vector is *special*. Vector is not *a class* in a typical sense.
>> It is
>>>> the
>>>>> closest thing that as3 has to generics which, when used at a
>> class
>>>> level, I
>>>>> like to think of as the ability to generate multiple class
>> variations
>>>> from
>>>>> a single class definition (that is just the way I think of
>> them). So,
>>> at
>>>>> some level Vector could be considered as an infinite set of
>> distinct
>>>>> classes, based on an infinite set of possible specified element
>> types
>>>>> (whatever you see between the angle brackets in code). It is not
>>> actually
>>>>> implemented natively in AVM this way iiuc, but that is the
>> outward
>>>>> appearance, and that is also the behaviour it has when using type
>>>> checking
>>>>> in as3.
>>>>>
>>>>> Aside from the runtime typesafe behaviour, Vector’s strong
>> typing means
>>>>> there is additional compile time support and, related, the
>> possibility
>>> of
>>>>> extra IDE support, both of which help the developer.
>>>>>
>>>>> Vector ‘types’ are also final ‘classes’ enforced by the
>> compiler, so
>>>> cannot
>>>>> be extended.
>>>>>
>>>>> Additionally, on looking closer, there are some other quirky
>> rules for
>>>>> runtime typing behaviour. These are related to the
>> implementation in
>>> AVM.
>>>>> The 3 Vector types for Vector.<int>, Vector.<uint>, and
>> Vector.<Number>
>>>> are
>>>>> individual base types, and then there is a 4th base type,
>> Vector.<*>
>>>> which
>>>>> serves as the ‘base class’ of all other Vector ‘subclasses’. The
>> 3
>>>> numeric
>>>>> types are faster than Array, and I expect this was the reason
>> for the
>>>>> separation, because these are used in a lot of other flash apis,
>>>>> particularly for swapping with byte level data and things like
>>> BitmapData
>>>>> etc. The others are more simply for the strong typing aspects,
>> because
>>>>> (perhaps less so with Boolean and String at a guess) they are
>> somewhat
>>>>> slower than Array in AVM, because of the overhead of runtime
>>> typechecking
>>>>> and coercions etc. So the main selling points for choosing a
>> Vector in
>>>>> flash were a) compile time and runtime type safety and b) faster
>>>>> performance for the 3 numeric Vector types.
>>>>>
>>>>> One implication of these ‘rules’ means that to check if
>> *something* is
>>> a
>>>>> Vector of any type in swf, I need to do (mything is Vector.<int>
>> ||
>>>> myThing
>>>>> is Vector.<uint> || myThing is Vector.<Number> || myThing is
>>> Vector.<*>)
>>>> or
>>>>> use reflection (which is slower).
>>>>>
>>>>> The above implies that, for language conformance (considered as
>>>> conformance
>>>>> with as3 documentation/spec and the behaviour of the reference
>>>>> implementation that we have for any ‘unknowns’) in an emulation,
>> a
>>>> regular
>>>>> single as3 class implementation would not create a result that is
>>>>> consistent with the spec in terms of its representation of
>> typing, and
>>>> its
>>>>> behaviour when using type checking.
>>>>>
>>>>> I tried to take all of these things into consideration.
>>>>>
>>>>>
>>>>>
>>>>> *How is it implemented in the branch?*
>>>>>
>>>>> Vector is implemented using the lightweight ‘synthType’ approach
>> I
>>> added
>>>>> previously to support for int and uint types as ‘classes’. This
>>> provides
>>>> a
>>>>> light integration for ‘is’ and ‘as’ checks, but in javascript
>> itself a
>>>>> Vector instance is simply a tagged native javascript Array
>> instance
>>> (i.e.
>>>>> an Array with something that identifies it as being ‘not a
>> regular
>>>> Array’).
>>>>> The Array methods are enhanced at the instance level to support
>> the
>>> type
>>>>> coercions that take place in an actionscript Vector. Using Array
>> makes
>>>>> sense because Vector instances are essentially typed Arrays. But
>> it is
>>>> not
>>>>> possible to extend Array in javascript and have things work
>> properly
>>> (it
>>>> is
>>>>> possible to use a different approach with es6 Proxy, but that is
>> not
>>>>> available in IE11).
>>>>>
>>>>> This implementation also means that a ‘Vector’ instance should
>> have
>>>>> functionality that works mostly as expected if it is passed
>> directly to
>>>> a 3
>>>>> rd party native javascript library that is expecting an Array
>> instance.
>>>> It
>>>>> will not support errors when changing the length if the Vector
>> instance
>>>> is
>>>>> ‘fixed’ length, for example but otherwise it should function
>> much the
>>>> same
>>>>> as a regular Array in the 3rd party code.
>>>>>
>>>>> The ‘synthType’ approach can be used because Vector types are
>> final, so
>>>> it
>>>>> does not need to conform to a regular Royale class definition
>> that can
>>> be
>>>>> extended and can be much ‘lighter’. As with int and uint
>> ‘classes’, no
>>>>> Vector constructor exists until the first one is requested.
>> There is
>>> one
>>>>> internal private class in Language that provides most of the
>>>> functionality
>>>>> for Vector, and element coercion functions are generated
>> specifically
>>> for
>>>>> each Vector ‘subtype’. Overall, it behaves more like a subclass
>>> ‘factory’
>>>>> with each individual type’s constructor being created on demand
>> and
>>>> cached
>>>>> for future use.
>>>>>
>>>>> Reflection and serialization support have not been added yet,
>> but I
>>>>> certainly had these in mind also with this approach. I just
>> wanted to
>>>> reach
>>>>> a sensible intermediate point for now, and then add those in
>> later.
>>>>>
>>>>> In summary, the Vector implementation in the branch provides the
>>>> following:
>>>>>
>>>>> -distinct types (conforming in terms of type checking) for each
>> Vector
>>>>> subtype
>>>>>
>>>>> -lightweight integration with Language ‘is’ and ‘as’ support
>>>>>
>>>>> -each Vector subtype has a unique constructor generated the
>> first time
>>> it
>>>>> is requested, the constructor does not exist prior to that.
>>>>>
>>>>> -expected to be compatible with 3rd party native javascript that
>>> expects
>>>> a
>>>>> regular javascript Array
>>>>>
>>>>> -serialization (amf) and reflection are not yet supported but
>> were
>>>>> considered, and that is planned as next steps.
>>>>>
>>>>> As at the time of writing, the current implementation is
>> supported by
>>> 300
>>>>> Vector-specific assertions that run side-by-side between
>> javascript and
>>>> swf
>>>>> in the manualtest UnitTests project. Apart from the differences
>> created
>>>> by
>>>>> explicitly switching off some type safety checks with
>>>>> @suppressvectorindexchecking, there is only one verifiable
>> difference
>>> in
>>>>> these tests between swf and javsacript. Probably there are things
>>> outside
>>>>> the test coverage that might need addressing still, but I think
>> it’s a
>>>>> pretty good start.
>>>>>
>>>>> These tests should be easily ported to framework level unit tests
>>>>> (RoyaleUnit) as the same approach has been used to add FlexUnit
>> tests
>>> in
>>>>> the past. Testing/Development is primarily in Chrome on windows,
>> but
>>> the
>>>>> same tests were subsequently verified on IE11, Edge, Opera and
>> Firefox
>>> on
>>>>> windows.
>>>>>
>>>>> *Implementation Info*
>>>>>
>>>>> *More quirks*
>>>>>
>>>>> A ‘fixed == true’ Vector cannot have its length changed. This
>> means
>>> that
>>>>> changes via the length setter and the mutation methods (push,
>> pop,
>>> shift,
>>>>> unshift etc) all throw errors if used when a Vector is ‘fixed ==
>> true’.
>>>>> But… splice method also can change length. And in AVM this works
>> even
>>>> with
>>>>> a fixed length Vector, which might possibly be a bug but is one
>> that is
>>>>> matched in the implementation to conform with flash.
>>>>>
>>>>> *Size impact.*
>>>>>
>>>>> Alex was concerned with size impact for HelloWorld because the
>> beads
>>> were
>>>>> using a Vector.<IBead> type in javascript in one of the
>> application
>>>>> framework base classes. But the requirement was for that to
>> simply to
>>> be
>>>> an
>>>>> Array in javascript, the compiler was only achieving that by
>> default
>>>>> because there was no real Vector implementation. So I did a
>> couple of
>>>>> things here. Firstly I changed the application framework code to
>>> reflect
>>>>> the different requirement for javascript. Secondly, I added some
>> doc
>>>>> comment directives to suppress exporting on public members. Then
>> I
>>> added
>>>>> this to the Language methods that are for compiler-generated
>> Vector
>>> (and
>>>>> int and uint) support so that they are eligible for dead code
>>> elimination
>>>>> if not used. This effectively means that it is fully PAYG – it
>> is only
>>>>> there if you need it, but if you need it there is also no effort
>> to add
>>>> it
>>>>> in as an optional dependency. If, because of this, there is a
>> potential
>>>> for
>>>>> issues with modules or something I have not thought of, that
>> will be
>>>>> another thing to solve, but if so, I will find a way to address
>> it.
>>>>>
>>>>> If the main concern with ‘size’ is data transfer, then looking
>> at the
>>>>> minified output size in HelloWorld is not really meaningful (or
>> perhaps
>>>> it
>>>>> is better to say that it is only as meaningful as looking at the
>> size
>>> of
>>>> an
>>>>> uncompressed swf compared to normal deployment of a compressed
>> swf). In
>>>> any
>>>>> real deployment the javascript should be served as gzipped. So I
>>> compared
>>>>> gzipped (‘normal’ compression) versions of HelloWorld.js between
>> those
>>>> with
>>>>> the unused Language support methods (for int/uint and Vector)
>> and their
>>>>> dependencies vs. builds without. The support for all that
>> functionality
>>>>> comes in at under 3 Kb difference in the gzipped output. I
>> personally
>>>> don’t
>>>>> think that would register as important in most cases. However,
>> it is
>>>> pretty
>>>>> close to zero impact now if it is not used. In fact the
>> HelloWorld
>>>>> application is now about 55 bytes smaller than it was before, so
>> I
>>>> consider
>>>>> it ‘carbon-netural’. And these are at the gzipped levels (it is
>> also
>>>>> slightly smaller when not gzipped, although it can sometimes be
>> the
>>> case
>>>>> that the larger of 2 files compresses better than a smaller one,
>>>> depending
>>>>> on the content).
>>>>>
>>>>> As a general comment about size… in my experience over the last
>> 10
>>> years
>>>> or
>>>>> so, mostly in relation to Flex apps, size was most often not
>> among the
>>>>> highest priority issues. Sure, start-up time often was. But that
>> is not
>>>>> size per se. Often ‘size’ issues were first and foremost ‘asset
>> size’
>>>>> issues (embedded or separate). While I know overall that it
>> remains
>>>>> important, I personally think the growth in bandwidth and device
>> memory
>>>> in
>>>>> general has outpaced the growth in the size of web apps even as
>> the
>>> world
>>>>> has turned to mobile. In other words, I think we probably passed
>> a
>>> hurdle
>>>>> point in the mobile side of things. Admittedly that is just
>>> ‘perception’
>>>>> and maybe there is data that shows I am quite wrong or your
>> experience
>>> on
>>>>> specific client projects could be quite different. The point of
>> me
>>>>> explaining that was, however, to illustrate why I think ‘size’
>> sits
>>>> where I
>>>>> think it does in general in terms of importance: I consider it
>> to be
>>>> behind
>>>>> stability/reliability first which is followed by performance in
>>>> performance
>>>>> critical code. Overriding that general flow (which again, is
>> just my
>>>>> opinion), are whatever my client’s specific requirements are for
>> any
>>>>> particular project. In other words I am not sure how much of
>>> HelloWorld’s
>>>>> size is going to be an important deciding factor for someone to
>> choose
>>> to
>>>>> use Royale. I think the ‘I got it to work!’ is the real kicker
>> here.
>>> This
>>>>> paragraph was not to cause any conflict, and I already addressed
>> the
>>>> ‘size’
>>>>> impact in the branch, so I’m not saying it wasn’t necessary to
>> do that
>>>>> (although I do suspect the same attention was not given to all
>> other
>>>> things
>>>>> in the past that affected HelloWorld). It’s more to promote
>> discussion
>>>> and
>>>>> thought in general. Trying to be all one aspect (small size) can
>>>> compromise
>>>>> other aspects (reliability or stability or compatibility, for
>> example).
>>>> And
>>>>> trying to accommodate all aspects (reliability, small size,
>> exceptional
>>>>> performance) somehow very likely increases complexity because
>> there is
>>> a
>>>>> need to accommodate the explicit decisions for trade-offs between
>>>> competing
>>>>> aspects. It would be good to have a guide of priorities based on
>> the
>>>> needs
>>>>> of the user base (while I might have a strong opinion about what
>> I
>>> think
>>>> is
>>>>> important, I don’t assume that my views necessarily represent
>> wider
>>> user
>>>>> needs, because I have not done research to support that – and
>> it’s not
>>>>> really a twitter poll kind of thing!). Anyhow I got off track
>> there a
>>>> bit…
>>>>> back to Vector…
>>>>>
>>>>>
>>>>>
>>>>> *Performance.*
>>>>>
>>>>> No-one should expect a non-native Vector implementation to
>> perform
>>> faster
>>>>> than native Array in javascript. Its main benefit is type
>> safety, and
>>>> that
>>>>> is the reason it should be selected for use over Array. (In swf,
>> native
>>>>> numeric Vector types *are* selected for performance, but the
>> other
>>> Vector
>>>>> types are also at least slightly slower than Array, so selecting
>> them
>>> is
>>>>> based on the need for type safety)
>>>>>
>>>>> There are, however some ways to get 100% Array performance with
>> this
>>>>> implementation, and in a loop, for example it would be similar to
>>>> avoiding
>>>>> method calls (like push/pop) and only using index assignments
>> that is
>>>>> typical of performance optimization in swf.
>>>>>
>>>>> So these two methods provide almost Identical performance in js:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *private function testArrayInt2(iterations:uint):Number{ var
>>>> start:Date
>>>>> = new Date(); var inst:Array = new Array(iterations);
>> for
>>>> (var
>>>>> i:uint=0;i<iterations; i++) { inst[i] = i; }
>> return new
>>>>> Date().valueOf() - start.valueOf(); } /** * *
>>>>> @royalesuppressvectorindexcheck true */ private function
>>>>> testVectorInt2(iterations:uint):Number{ var start:Date = new
>>> Date();
>>>>> var inst:Vector.<uint> = new Vector.<uint>(iterations);
>> for
>>>>> (var i:uint=0;i<iterations; i++) { inst[i] = i; }
>>> return
>>>>> new Date().valueOf() - start.valueOf(); }*
>>>>>
>>>>> The doc comment on the 2nd method prevented the compiler from
>>> generating
>>>> an
>>>>> index check wrapper around the ‘i’ in inst[i]
>>>>>
>>>>> The above 2 methods take around 5-7 ms for 500,000 iterations on
>> my
>>>> machine
>>>>> (chrome/windows). This is quite a bit faster than the same
>> methods in
>>> the
>>>>> swf (non-debug) build on my machine. The Vector constructor is
>> also
>>> doing
>>>>> extra work in this case by setting all the 500,000 slots to
>> numeric 0.
>>>> But
>>>>> on modern browsers it is using a fast native Array.fill method
>> to do
>>>> that,
>>>>> so it’s probably more noticeable on IE11 which uses a for loop to
>>>>> pre-populate the contents with numeric 0 values.
>>>>>
>>>>> For reference, the generated code for the second method above,
>> looks
>>> like
>>>>> this:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> */** * * @royalesuppressvectorindexcheck true * @private *
>> @param
>>>>> {number} iterations * @return {number} */
>>>>>
>>>>>
>>>>
>>>
>> flexUnitTests.language.LanguageTesterTestVectorPerf.prototype.flexUnitTests_language_LanguageTesterTestVectorPerf_testVectorInt2
>>>>> = function(iterations) { var /** @type {Date} */ start = new
>> Date();
>>>>> var /** @type {Array.<number>} */ inst = new
>>>>>
>> (org.apache.royale.utils.Language.synthVector('uint'))(iterations);
>>> for
>>>>> (var /** @type {number} */ i = 0; i < iterations; i++) {
>> inst[i] =
>>> i;
>>>>> } return new Date().valueOf() - start.valueOf(); };*
>>>>>
>>>>> The methods with type checking in them, like push, unshift etc
>> will be
>>>>> quite a lot slower though. This should not be a surprise. In
>> swf, when
>>>> you
>>>>> look at something like Vector.<IBead> it can be up to 30% slower
>> than
>>>> Array
>>>>> for methods like push, iirc at native level. In javascript it
>> will be a
>>>> lot
>>>>> more. But in both cases it has type safety. And for small
>> collection
>>>> sizes
>>>>> in non-performance sensitive code it is probably not going to
>> make a
>>>>> meaningul difference.
>>>>>
>>>>> Known limitations
>>>>>
>>>>> 1. myVectorInstance[‘constructor’] can be different
>> between js
>>> and
>>>>> swf
>>>>>
>>>>> 2. There is some reliance on not obscuring the type from
>> the
>>>> compiler
>>>>> for things to work correctly. Example:
>>>>>
>>>>> var myObscuredType:* = new Vector.<String>(20,true) // creates a
>> fixed
>>>>> Vector of length 20
>>>>>
>>>>> myObscuredType.length = 21; //should throw an error, but does
>> not in
>>>>> javascript.
>>>>>
>>>>> This will work as long as the compiler knows that the type with
>> the
>>>> length
>>>>> setter is some type of Vector, otherwise not.
>>>>>
>>>>>
>>>>>
>>>>> *Performance tuning*
>>>>>
>>>>> *@royalesuppressvectorindexcheck*
>>>>>
>>>>> The above doc comment directive avoids checking for
>> out-of-valid-range
>>>>> index values on assignments. This is extremely desirable inside
>> loops
>>>> which
>>>>> are usually constrained to the valid range in any case. There is
>> a top
>>>>> level compiler configuration setting for this, but local
>> settings win
>>>>> (turning off or on generally with true/false, or suppressing
>>> specifically
>>>>> for individual local variable names)
>>>>>
>>>>>
>>>>>
>>>>> Other options.
>>>>>
>>>>> The above one was obvious to me as an important tuning option. I
>>> started
>>>>> with adding another but pulled it out in favor of adding them
>> based on
>>>>> actual need.
>>>>>
>>>>> There are many options:
>>>>>
>>>>> Instance based: reducing type checking with a compiler-only
>> generated
>>>>> additional constructor parameter, triggered by some doc comment
>>>> directive.
>>>>> This could be in the form of adding in compiler generated
>> alternatve
>>>> calls
>>>>> to things like ‘unsafePush’ and ‘unsafePop’ on instances, or
>> perhaps
>>>>> literal calls to Array.prototype.push.call(inst, pushItem),
>> triggered
>>> by
>>>>> some doc comment directive
>>>>>
>>>>> Global changes:Adding some compiler define value that (along
>> with:
>>>>> ||goog.DEBUG) suppresses many runtime checks in the release
>> Vector
>>>>> implementation. This would allow a blanket approach to dialing
>> runtime
>>>>> safety down (or keeping them) in the release build. It would
>> apply
>>> across
>>>>> all libraries and local project code.
>>>>>
>>>>> Some combinations of the above that allow sweeping optimizations
>> with
>>>> local
>>>>> exceptions.
>>>>>
>>>>> Basically, this branch currently represents what I have reason to
>>> believe
>>>>> is a high conformance Vector implementation which should be the
>> default
>>>> as
>>>>> it is an as3 core type. I think there are many options to scale
>> things
>>>>> back, but rather than assume what they should be, I’d prefer to
>> hear
>>> from
>>>>> users and address *real* needs, so that we only end up with
>>> configuration
>>>>> options that matter.
>>>>>
>>>>>
>>>>>
>>>>> *Advantages of a single Vector implementation – the case for
>> avoiding a
>>>>> ‘vector emulation class’*
>>>>>
>>>>> ‘Language emulation’ is a foundational layer that is not in the
>> same
>>>>> category as ‘application framework’ where we can define things
>> how we
>>>> want.
>>>>> Because the royale sdk includes both aspects inside ‘framework’
>> (and
>>> that
>>>>> was obviously not the case for flex sdk in the past) it may be
>> easy to
>>>>> overlook that difference.
>>>>>
>>>>> Vector typing is a core part of AS3 language. Therefore it should
>>> conform
>>>>> and be reliable. Having multiple implementations for a core
>> language
>>>>> feature seems wrong and could easily lead to libraries of code
>> that are
>>>>> incompatible. Additionally, as pointed out earlier, Vector is
>> more
>>> like a
>>>>> subclass factory (‘runtime’ generics) than a single class, so
>> won’t be
>>>> well
>>>>> represented by a regular class implementation.
>>>>>
>>>>> Alex, I know you added support for a Vector emulation class
>> approach to
>>>>> meet the needs of someone asking for improved Vector support, in
>> part
>>>>> because we did not have someone who had volunteered to write our
>> own. I
>>>> did
>>>>> that last part now. I am also suggesting that the emulation class
>>>> approach
>>>>> is not a good long term solution because of the above reasons.
>> And the
>>>> full
>>>>> set of functionality is less than 3Kb in the gzipped output, so
>> I’d
>>>> suggest
>>>>> that as long as I can add needs-based performance tuning options
>> for
>>>> those
>>>>> who want them, the benefits of having a single conforming
>>> implementation
>>>>> which is performance scalable are better than the risks
>> associated with
>>>>> adding partially non-conforming ones. Therefore I’d like to ask
>> if we
>>> can
>>>>> remove that functionality now that we have our own 'Vector' (I
>> can do
>>> the
>>>>> work if you prefer as I know your focus is understandably on
>> other
>>>> things).
>>>>>
>>>>> *Future:*
>>>>>
>>>>> It will be easily possibly to alter the current implementation
>> to use
>>> es6
>>>>> proxy which would likely provide the most reliable way to get
>> full
>>> Vector
>>>>> conformance indistinguishable from flash. Es6 proxy is
>> transparent for
>>>>> Array:
>>>>>
>>>>> var p = new Proxy(new Array(), {});
>>>>>
>>>>> Array.isArray(p) // true
>>>>>
>>>>> This should allow trapping things like the length setter before
>> it gets
>>>> to
>>>>> the underlying Array target, and doing checking for fixed ==
>> true etc.
>>>> The
>>>>> same is true for numeric index-based assignment of values etc.
>>>>>
>>>>> es6 Proxy is kinda cool. At the moment IE11 is the only
>> meaningful
>>> target
>>>>> that does not support this.
>>>>>
>>>>> I am only mentioning this here because I did think about this,
>> and I
>>>>> believe that the current implementation could be upgraded quite
>> easily
>>> to
>>>>> use this approach if it makes sense (when IE11 is a distant
>> memory –
>>>>> perhaps sometime next year!).
>>>>>
>>>>>
>>>>>
>>>>> Phew, you made it! Well done.
>>>>>
>>>>> Feel free to share your thoughts or ask any questions you might
>> have.
>>> If
>>>>> you have neither of those at this time, please still try to find
>> time
>>> to
>>>>> test any large projects you have in the branch, and provide
>> feedback or
>>>>> share any concerns you might have after doing that.
>>>>> thanks,
>>>>> Greg
>>>>>
>>>>>
>>>>> On Thu, May 23, 2019 at 7:55 PM Greg Dove <greg.dove@gmail.com <ma...@gmail.com>>
>> wrote:
>>>>>
>>>>>> Re XMLTest manualtest...
>>>>>>
>>>>>> Yep those were the ones I ported, Harbs. I think I got them
>> all but
>>> may
>>>>>> have missed some. I added a bunch more as well. Hopefully
>> these can
>>> be
>>>>>> easily migrated to what Josh has been working on.
>>>>>>
>>>>>>
>>>>>> On Thu, 23 May 2019, 19:43 Harbs, <harbs.lists@gmail.com <ma...@gmail.com>>
>> wrote:
>>>>>>
>>>>>>> As far as XML unit tests go, the starting point should be
>> XMLTest in
>>>>>>> manual tests. (Almost) every time I ran into an issue, I
>> added it to
>>>>> that
>>>>>>> project.
>>>>>>>
>>>>>>> I think I might have been lax on the last few issues I fixed,
>> so we
>>>>>>> should probably go through the later XML commits and make
>> sure we
>>> have
>>>>>>> tests for that.
>>>>>>>
>>>>>>> As far as Node goes, I think we probably need conditional Node
>>>>>>> compilation to handle Node-specific (and browser specific)
>> code in a
>>>>> PAYG
>>>>>>> way.
>>>>>>>
>>>>>>> To technically handle the parsing, something like
>>>>>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0>
>> <
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0>
>>>
>>>> is
>>>>> a
>>>>>>> good starting point and something like this
>>>>>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0>
>> <
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0>
>>>
>>>>>>> might be useful to either use or modify.
>>>>>>>
>>>>>>> Harbs
>>>>>>>
>>>>>>>> On May 23, 2019, at 10:18 AM, Greg Dove <
>> greg.dove@gmail.com <ma...@gmail.com>>
>>>> wrote:
>>>>>>>>
>>>>>>>> All, I started porting some adhoc XML tests to UnitTests and
>>>>> eventually
>>>>>>>> ended up spending quite a bit of time on addressing issues
>> that
>>>> arose
>>>>>>> for
>>>>>>>> XML before getting back to Vector stuff.
>>>>>>>> I think XML probably needs many more unit tests before we
>> get to
>>> 1.0
>>>>>>>> because it has an extensive api. I have not used royale
>> with Node
>>>> yet,
>>>>>>> but
>>>>>>>> XML also needs some thought about how to get it working on
>> Node, I
>>>>>>> assume.
>>>>>>>> Because XML uses the browser's parser and Node does not
>> have one
>>> by
>>>>>>>> default, then using the same code will need something to
>> take the
>>>>> place
>>>>>>> of
>>>>>>>> the browser's native parser for Node. There is a lib in npm
>> that
>>>> might
>>>>>>> be
>>>>>>>> useful for that, but I don't know how that might work with
>> licence
>>>>> etc.
>>>>>>>> Anyhow, that is just an observation, I will focus on Vector
>> in
>>> this
>>>>>>>> thread... I will post here late tomorrow local time with
>> more
>>> info,
>>>>> and
>>>>>>>> discussion points. I am keen to see this merged in, but
>> also keen
>>> to
>>>>> get
>>>>>>>> buy-in first.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <
>>>>> carlosrovira@apache.org <ma...@apache.org>
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> 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.dove@gmail.com <ma...@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.dove@gmail.com <ma...@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
>>>> <aharui@adobe.com.invalid <ma...@adobe.com.invalid>
>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> +1 to renaming the options to the positive.
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <
>> joshtynjala@apache.org <ma...@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.dove@gmail.com <ma...@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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=vC7Sy%2BfGwJhbS8bR0Eo4wZBTNxsuEGCWXQ6nHceAk18%3D&reserved=0 <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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=vC7Sy%2BfGwJhbS8bR0Eo4wZBTNxsuEGCWXQ6nHceAk18%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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=NlTd48QGPtLVuoxX%2Fv4IO0ZZyz3CMgh7Gzllr3D%2BIoA%3D&reserved=0 <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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=NlTd48QGPtLVuoxX%2Fv4IO0ZZyz3CMgh7Gzllr3D%2BIoA%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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=dwgAt0Rz%2Bt575HRIk97kPbtewGN4mSv8FbCQr6Skudg%3D&reserved=0 <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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=dwgAt0Rz%2Bt575HRIk97kPbtewGN4mSv8FbCQr6Skudg%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
>>>>>>>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Carlos Rovira
>>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0>
Re: Language improvements
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Greg,
I live outside of Seattle. I'm in my house right now, and my cellphone says I have a 4G connection. Many times a month, I take a ferry boat to Seattle. There is a point during the ride where the connectivity is poor. Yesterday, I was trying to get work done on the ferry and was blocked from doing one step in the release automation because it would not load in time. Many times, I'm trying to get one thing finished and get stymied by poor connectivity. I hear this complaint from plenty of other residents where I live. I want Royale to produce the app that loads when other apps don't. Forcing everyone to take on another 2000+ bytes is not going to help.
The argument of "it is only another 1K" is what eventually caused UIComponent to grow to 13,000 lines and 128K Hello World. That's history. I do not want to repeat it.
I still haven't had time to look at your changes or read and respond to all of the words you've written. Mostly for others who haven't been following the discussion, my reasoning is as follows:
-Vector and XML and any other built-in for SWF that isn't in JS are not free. We have to write some amount of code to get them to work.
-Vector provides runtime type checking. Not everybody needs runtime type checking in production.
-Vector provides length checking. Not everybody needs length checking in production.
-We've already proven that by having at least two projects get into production without your implementation of Vector.
-The current compiler output for Vector for folks who don't need runtime checking just uses Array.
-Your implementation adds 2990 bytes.
For sure, we need an implementation that does runtime type-checking and length checking. So, as long as folks can choose to save the 2990 bytes and just use the current compiler output for Array in production, then we have given folks the right choices. Bonus if we can let folks choose other Vector implementations just like they can choose other XML implementations. My understanding from the words you've written is that you want everyone to use your Vector implementation and have options on what code paths that implementation actually takes, but I don't understand why from a technical perspective.
In fact, I was reading up on Javascript TypedArrays (because that did load while on the ferry) and it looks like some folks might want Vector.<int> to map to the appropriate TypedArray. It actually got me wondering if folks should be able to dictate how any particular instance of a Vector "optimizes".
In sum, the download size still matters. I see it quite frequently. Technically, why shouldn't folks have a choice of implementations?
-Alex
On 5/27/19, 2:46 AM, "Greg Dove" <gr...@gmail.com> wrote:
Hi Alex, sorry it can take a while for me to reply at the moment... some
comments inline below...
On Sun, May 26, 2019 at 11:10 AM Alex Harui <ah...@adobe.com.invalid>
wrote:
> Hi Greg,
>
> Thanks for working through all of this. Better Vector handling is
> definitely a good thing for Royale.
>
I also believe so. In terms of my motivation for doing this work... I
actually have no imminent need for Vector, but I wanted to do something
concrete which I think is essential for 1.0.
I do have my own libraries and past client work from that use Vector, so I
see benefit in knowing that it will be easy to port to Royale and work
without any issues if I need to do that at any point (hopefully I will). I
also got to see how Vector was treated differently/specially when working
on AMF, and realized that we had no way to support it there correctly
because it is 'special' also in amf, so that was another motivation (again,
not for anything I actually need at the moment for myself or anyone else,
but because it is something else that is lacking for 1.0).
However, IMO, PAYG is more important and 3KB can be a full second or more
> on busy/slow/poor networks. As such, folks need to have choices. So as
> long as folks can choose Vector implementations we should be good.
>
> A couple of things here. Firstly, I really did not think I would need to
be this specific... but iirc it was actually 2990 bytes.
My first reaction to your scenario above would be: that network connection
speed is really *unusable* for anything on today's internet... and that is
a problem that should be addressed first, otherwise it does not matter
which development tech you plan to use, it will be a common problem,
royale, react... whatever.
I can't recall something from my last 10 years where 3KB would be
considered a driving force for an intervention that would (presumably) only
save a portion of that (and introduce future potential maintainability
risks). 3KB was less than a second on dialup over 20 years ago. Things have
changed dramatically in the last 5 years in particular. We are in a HD
streaming world now, with many countries supporting 4K streaming connection
speeds. And average speeds continue to grow globally at solid rates
year-on-year. 4G has impressive global coverage, and 5G is on the horizon.
I did mention this generally my earlier comments about bandwidth growth
outpacing growth in the size of apps. With your example are you
hypothesizing or do you have a real recent example in mind where this type
of thing was happening? If I was asked to classify the likelihood of the
scenario you described I would describe it as a few standard deviations
away from the center of the bell curve based on my own experience.
However I absolutely do agree with you that choice is important, I just
believe that performance most often will be more of a reason for the
decision to choose alternates (and it may mean adding 'size', not reducing
it).
And I think the choice should be explicit/obvious rather than having
something that is a lesser implementation of what it is actually supposed
to be. By this, I mean more application framework alternatives, instead of
supporting variations that represent non-conforming language classes. If
that approach is used, I think it will result in clearer, better quality,
more maintainable code. This is also a general approachI have observed
elsewhere.
Choosing Array is always an option in javascript and provides a zero
byte-weight option. I also plan to introduce some options for the numeric
types that represent best performance across both targets... but not as
'Vector' numeric types. The aim here would be to get faster than 'Vector as
Array' in javascript and it will be just a convenience approach to avoid
writing your own COMPILE::JS blocks with the native TypedArrays.
In terms of tweaking this Vector implementation's performance as further
options, I already explained I am happy to work on that based on actual
feedback for need. But I still think it requires caution and consideration
in terms of potential risks for people releasing libraries that could
expose non-conforming instances of Vectors (something that can never happen
in swf).
There are perhaps some possibilities for enhancing [ArrayElementType] with
a compiletime=true argument to get something more like what Harbs is after,
but that would only work for class members, not local vars. Perhaps there
are other simple ways to add 'compiletime' safety without going to full
blown generics support yet.
> Flex failed in some major vendors' customer-facing apps because of
> download times. I have spent the past years trying to make sure Royale
> does not repeat those mistakes.
>
>
I do want you to understand that I'm on the same team. And like you, I
don't want to repeat old mistakes too. But I also would like to see us
avoid possible new ones.
In the last 5 years or so, I have never really had a client spend much time
focusing on the size. Before that I think I was more aware of it. Anyhow,
it's not that it was never important at all, it's just that it was
relatively unimportant compared to other aspects. And apart from
remembering the size of flex apps in the past, I've seen the size of react
apps I worked on recently too.
I actually just looked at one of those. It is 8762KB minified and
compresses to 1293KB gzipped. The app does not compare directly, but it is
similar to Carlos' app in that it has many complex input rules and
sequences, however in a lot of ways Carlos' app is far more complex and has
a lot more remote API calls. However the final result from royale with
Carlos's app has a much, much lighter footprint than those numbers for
react. So Alex, I think the work you and others have put into avoiding
unneeded weight in the application framework has paid (and will continue to
pay) 'dividends' (as a metaphoric expression for anyone unfamiliar with
that).
But I do think of the language layer below the application framework layer
as 'different' and that it should be treated as if it has existing
specifications that are not free to reshape as we see fit (which it does,
directly or indirectly). The language is still actionscript, it's not
royalescript or jactionscript or something else. I've also spelt out a
number of the reasons why I have these views earlier. One thing I did not
mention was that my views also reflect my experience and observations with
another cross platform language. I have seen some cases, for example, where
over the course of iterative improvements, the use of native classes (the
example that springs to mind was for XML parsing) was removed from a
language level library and the whole feature was re-implemented in local
code because it was more desirable to achieve consistency across targets
than to have the best performing code on any one target. The IDE plugin for
that particular sdk has over 120K downloads in the one IDE I use most often
and it has a number of other IDEs supporting it with their own plugins etc.
So I have reason to believe it is popular, and I know it is disciplined at
the language level for a number of these shared target aspects. The
consistency therefore seems to be very important to its user base, more so
than the prospect of each language level feature 'being the smallest it can
be'. But beyond the core language it also has lots of scope for
accommodating differences. My exposure to this (and involvment with it in
the past) has also influenced my thinking. I try to avoid thinking "that's
them and not us" because that is a poor reason to ignore the learnings of
others. Much of my own knowledge and skills over the years is the result of
shared knowledge (royale and yourself included as a boost to that for which
I am grateful). Anyway, part of the thinking does come from awareness of
other things elsewhere, but I did pass it through my 'how does it relate to
royale' filter.
I have some comments on finer details, but let's see if we can agree on
> this higher-level issue first. We simply should offer people choices.
>
> Just repeating: I too am keen to offer choices and also to make it easy to
choose them. We only have different views over what those choices should
be. I would prefer them to be safer choices. I believe avoiding the
multiple Vector implementation approach will avoid future pitfalls and
possible developer confusion that could arise from the distribution of
inconsistent or non-conforming language level code. Neither of us can be
certain if those risks are real. But there is one way to avoid them for
sure (and yet still provide choices). That is essentially the crux of my
thinking. Do you think that logic is reasonable at the higher-level?
Beyond that, I did not obviously remove any emulationClass code in the
compiler and would not do so without your agreement, so nothing there has
changed.
Actually in the branch I think I changed something to pass qualified name
instead of basename somewhere, because base name would not be correct in
the general case. For that reason I don't think anybody was using that
feature yet, although I know you added it in response to a request from
Joshua Granick, as a way to address the Array-not-Vector issue. I do not
think it should be there now that we have something that we can call our
own, which is why I asked if we could remove it. Anyway, in terms of that
decision, can we agree to table it for now, merge the branch and maybe
continue this discussion later? I will go ahead and work on the other
'choices' I have in mind regardless, maybe when you see them you might
change how you think about things (or not, it is the apache way).
> Thanks,
> -Alex
>
> On 5/25/19, 2:45 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Hi Carlos, thanks for your feedback. In terms of PAYG, I just have a
> sense
> that at the language level, the 'default' should be that it *works* as
> per
> design.
> If I take the example of Vector... then numeric Vector types will not
> run
> faster in javascript. Using all the method calls will have a
> substantial
> impact compared to using a normal Array. But code should 'work' the
> same
> across targets.
> I do have some ideas for application framework classes outside
> 'language'/Vector that would provide target-agnostic fast regular class
> implementations for numeric typed Arrays, and I hope to work on that
> soon
> as well, which takes more advantage of the optimized native options on
> each
> target (Vector in swf, TypedArray in javascript). But to achieve that
> it
> will likely be 'always fixed length' in this case, I will see if it
> seems
> worth trying to be able to toggle that, or maybe it can be a bead or
> opt-in
> support to get that functionality. But that should provide a good
> option
> for developers seeking to get the best performance for numeric
> collections.
> I expect to work on this during June.
> Or developers can of course always choose to implement their own custom
> performance code in COMPILE::JS / COMPILE::SWF variations, which is
> always
> an option.
>
>
> Hi Piotr, sorry about that email formatting issue. Thanks for your
> follow
> up on this.
> Here is a paste of that part, which includes the code.
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdPWy&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=2InnN50ng8lXwYsDKMZXNiEoHCcMDutiw%2BmOAifDqdc%3D&reserved=0
>
> Also, if you want to see the tests for Vector, you can see them 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&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sp48jNSTgvHikdp9A2d2L%2Bwkq5vcHII%2BBqD%2BiXczSaQ%3D&reserved=0
>
>
> You should see large parts of that series of tests fail outside the
> branch, and in some cases there were compiler errors too iirc (or
> maybe I
> am confusing some compiler fixes I did for other things, can't be sure
> now)
>
>
>
> On Sun, May 26, 2019 at 4:58 AM Carlos Rovira <carlosrovira@apache.org
> >
> wrote:
>
> > Hi!
> >
> > Read it! :), was long but I think this emails are needed since it
> brings
> > many thoughts that only the developer knows and otherwise would end
> never
> > known by the rest of the community. So Great!
> >
> > Greg, first, many thanks for working on this. I think we get other
> point
> > solved, and I think not only Vector, but many other fixes and things
> coming
> > in your branch.
> >
> > For my part, as you said, the branch is tested against my real
> project,
> > that I think is a very good way to test against lots of working
> code. So
> > for my is ok to merge, not only cause it does not brake anything,
> but cause
> > it's a big step forward.
> >
> > Since it brings things we didn't have before like Vector, is good to
> bring
> > this. Then we can continue iterating to add missed things like AMF
> support
> > or to evolve to other state or even change internal things if other
> check
> > and see ways of enhancements.
> >
> > About the Vector implementation. My opinion is that I think as you
> that
> > Vector is an intrinsic part of AS3, so better to have an
> implementation to
> > complete AS3 in Royale. About having multiple implementations, I
> think that
> > could be good in the future if things can be done that way, but
> better
> > start from this starting point and see what happens in next
> months-years.
> > IOW, better have a real implementation now that a potentially one
> that
> > still is not here. We need to see the goal and approach to it
> progressively
> > or we end getting nothing since the goal is a huge one not easy to
> reach.
> >
> > For me the 3kb is totally normal, and as well a great achievement of
> your
> > implementation.
> > I must say that my way of thinking in Royale is to be totally
> aligned with
> > concepts like PAYG, but sometimes we need to break rules when the
> goal
> > demand it, or we can end trying to apply the same principle to all
> things,
> > when sometimes is not the best. So this is importante, rules are
> really
> > good, but we need to always put behind a layer of human thinking
> about what
> > we are trying to accomplish
> >
> > Thanks Greg for reaching another important milestone! Amazing work!
> :)
> >
> > Carlos
> >
> > PD: Piotr, about gmail cutting the email, I'm using gmail and get to
> read
> > it completely, maybe could be a problem of gmail in mobile? I'm
> reading on
> > gmail desktop. The only problem I had was reading posted source
> code, but
> > since it was tiny, I could finally read it...
> >
> >
> >
> >
> >
> > El sáb., 25 may. 2019 a las 15:37, Piotr Zarzycki (<
> > piotrzarzycki21@gmail.com>) escribió:
> >
> > > Hi Greg,
> > >
> > > Could you please post the code from this email in the
> paste.apache.org -
> > > right now is unreadable in my Gmail account.
> > >
> > > Thanks,
> > > Piotr
> > >
> > > On Sat, May 25, 2019, 4:51 AM Greg Dove <gr...@gmail.com>
> wrote:
> > >
> > > > OK, At the risk of making what follows even longer... a warning:
> *this
> > > is a
> > > > long read*. It might veer off topic in one or two places, but it
> is
> > > mostly
> > > > about why, and how Vector is implemented the way it is in the
> branch.
> > > > Basically I would like to merge this branch into develop as soon
> as
> > > > possible, i actually think it is ready as is, but I am keen to
> get
> > other
> > > > input before I do.
> > > > Read it if you're interested. If you're not interested in
> reading it
> > then
> > > > please try the branch on any 'real' projects that you have in
> play.
> > > Carlos
> > > > has tested against his, and there are no issues, but it would be
> good
> > to
> > > > get wider input.
> > > >
> > > > now to the textual onslaught:
> > > >
> > > >
> > > > *Vector*
> > > >
> > > > One of the things I did before I worked on this Vector
> implementation
> > was
> > > > to detach myself from ‘how I use Vector when I code’, to take a
> step
> > back
> > > > and challenge myself to rethink how I thought about it in
> general.
> > > >
> > > > Vector is *special*. Vector is not *a class* in a typical sense.
> It is
> > > the
> > > > closest thing that as3 has to generics which, when used at a
> class
> > > level, I
> > > > like to think of as the ability to generate multiple class
> variations
> > > from
> > > > a single class definition (that is just the way I think of
> them). So,
> > at
> > > > some level Vector could be considered as an infinite set of
> distinct
> > > > classes, based on an infinite set of possible specified element
> types
> > > > (whatever you see between the angle brackets in code). It is not
> > actually
> > > > implemented natively in AVM this way iiuc, but that is the
> outward
> > > > appearance, and that is also the behaviour it has when using type
> > > checking
> > > > in as3.
> > > >
> > > > Aside from the runtime typesafe behaviour, Vector’s strong
> typing means
> > > > there is additional compile time support and, related, the
> possibility
> > of
> > > > extra IDE support, both of which help the developer.
> > > >
> > > > Vector ‘types’ are also final ‘classes’ enforced by the
> compiler, so
> > > cannot
> > > > be extended.
> > > >
> > > > Additionally, on looking closer, there are some other quirky
> rules for
> > > > runtime typing behaviour. These are related to the
> implementation in
> > AVM.
> > > > The 3 Vector types for Vector.<int>, Vector.<uint>, and
> Vector.<Number>
> > > are
> > > > individual base types, and then there is a 4th base type,
> Vector.<*>
> > > which
> > > > serves as the ‘base class’ of all other Vector ‘subclasses’. The
> 3
> > > numeric
> > > > types are faster than Array, and I expect this was the reason
> for the
> > > > separation, because these are used in a lot of other flash apis,
> > > > particularly for swapping with byte level data and things like
> > BitmapData
> > > > etc. The others are more simply for the strong typing aspects,
> because
> > > > (perhaps less so with Boolean and String at a guess) they are
> somewhat
> > > > slower than Array in AVM, because of the overhead of runtime
> > typechecking
> > > > and coercions etc. So the main selling points for choosing a
> Vector in
> > > > flash were a) compile time and runtime type safety and b) faster
> > > > performance for the 3 numeric Vector types.
> > > >
> > > > One implication of these ‘rules’ means that to check if
> *something* is
> > a
> > > > Vector of any type in swf, I need to do (mything is Vector.<int>
> ||
> > > myThing
> > > > is Vector.<uint> || myThing is Vector.<Number> || myThing is
> > Vector.<*>)
> > > or
> > > > use reflection (which is slower).
> > > >
> > > > The above implies that, for language conformance (considered as
> > > conformance
> > > > with as3 documentation/spec and the behaviour of the reference
> > > > implementation that we have for any ‘unknowns’) in an emulation,
> a
> > > regular
> > > > single as3 class implementation would not create a result that is
> > > > consistent with the spec in terms of its representation of
> typing, and
> > > its
> > > > behaviour when using type checking.
> > > >
> > > > I tried to take all of these things into consideration.
> > > >
> > > >
> > > >
> > > > *How is it implemented in the branch?*
> > > >
> > > > Vector is implemented using the lightweight ‘synthType’ approach
> I
> > added
> > > > previously to support for int and uint types as ‘classes’. This
> > provides
> > > a
> > > > light integration for ‘is’ and ‘as’ checks, but in javascript
> itself a
> > > > Vector instance is simply a tagged native javascript Array
> instance
> > (i.e.
> > > > an Array with something that identifies it as being ‘not a
> regular
> > > Array’).
> > > > The Array methods are enhanced at the instance level to support
> the
> > type
> > > > coercions that take place in an actionscript Vector. Using Array
> makes
> > > > sense because Vector instances are essentially typed Arrays. But
> it is
> > > not
> > > > possible to extend Array in javascript and have things work
> properly
> > (it
> > > is
> > > > possible to use a different approach with es6 Proxy, but that is
> not
> > > > available in IE11).
> > > >
> > > > This implementation also means that a ‘Vector’ instance should
> have
> > > > functionality that works mostly as expected if it is passed
> directly to
> > > a 3
> > > > rd party native javascript library that is expecting an Array
> instance.
> > > It
> > > > will not support errors when changing the length if the Vector
> instance
> > > is
> > > > ‘fixed’ length, for example but otherwise it should function
> much the
> > > same
> > > > as a regular Array in the 3rd party code.
> > > >
> > > > The ‘synthType’ approach can be used because Vector types are
> final, so
> > > it
> > > > does not need to conform to a regular Royale class definition
> that can
> > be
> > > > extended and can be much ‘lighter’. As with int and uint
> ‘classes’, no
> > > > Vector constructor exists until the first one is requested.
> There is
> > one
> > > > internal private class in Language that provides most of the
> > > functionality
> > > > for Vector, and element coercion functions are generated
> specifically
> > for
> > > > each Vector ‘subtype’. Overall, it behaves more like a subclass
> > ‘factory’
> > > > with each individual type’s constructor being created on demand
> and
> > > cached
> > > > for future use.
> > > >
> > > > Reflection and serialization support have not been added yet,
> but I
> > > > certainly had these in mind also with this approach. I just
> wanted to
> > > reach
> > > > a sensible intermediate point for now, and then add those in
> later.
> > > >
> > > > In summary, the Vector implementation in the branch provides the
> > > following:
> > > >
> > > > -distinct types (conforming in terms of type checking) for each
> Vector
> > > > subtype
> > > >
> > > > -lightweight integration with Language ‘is’ and ‘as’ support
> > > >
> > > > -each Vector subtype has a unique constructor generated the
> first time
> > it
> > > > is requested, the constructor does not exist prior to that.
> > > >
> > > > -expected to be compatible with 3rd party native javascript that
> > expects
> > > a
> > > > regular javascript Array
> > > >
> > > > -serialization (amf) and reflection are not yet supported but
> were
> > > > considered, and that is planned as next steps.
> > > >
> > > > As at the time of writing, the current implementation is
> supported by
> > 300
> > > > Vector-specific assertions that run side-by-side between
> javascript and
> > > swf
> > > > in the manualtest UnitTests project. Apart from the differences
> created
> > > by
> > > > explicitly switching off some type safety checks with
> > > > @suppressvectorindexchecking, there is only one verifiable
> difference
> > in
> > > > these tests between swf and javsacript. Probably there are things
> > outside
> > > > the test coverage that might need addressing still, but I think
> it’s a
> > > > pretty good start.
> > > >
> > > > These tests should be easily ported to framework level unit tests
> > > > (RoyaleUnit) as the same approach has been used to add FlexUnit
> tests
> > in
> > > > the past. Testing/Development is primarily in Chrome on windows,
> but
> > the
> > > > same tests were subsequently verified on IE11, Edge, Opera and
> Firefox
> > on
> > > > windows.
> > > >
> > > > *Implementation Info*
> > > >
> > > > *More quirks*
> > > >
> > > > A ‘fixed == true’ Vector cannot have its length changed. This
> means
> > that
> > > > changes via the length setter and the mutation methods (push,
> pop,
> > shift,
> > > > unshift etc) all throw errors if used when a Vector is ‘fixed ==
> true’.
> > > > But… splice method also can change length. And in AVM this works
> even
> > > with
> > > > a fixed length Vector, which might possibly be a bug but is one
> that is
> > > > matched in the implementation to conform with flash.
> > > >
> > > > *Size impact.*
> > > >
> > > > Alex was concerned with size impact for HelloWorld because the
> beads
> > were
> > > > using a Vector.<IBead> type in javascript in one of the
> application
> > > > framework base classes. But the requirement was for that to
> simply to
> > be
> > > an
> > > > Array in javascript, the compiler was only achieving that by
> default
> > > > because there was no real Vector implementation. So I did a
> couple of
> > > > things here. Firstly I changed the application framework code to
> > reflect
> > > > the different requirement for javascript. Secondly, I added some
> doc
> > > > comment directives to suppress exporting on public members. Then
> I
> > added
> > > > this to the Language methods that are for compiler-generated
> Vector
> > (and
> > > > int and uint) support so that they are eligible for dead code
> > elimination
> > > > if not used. This effectively means that it is fully PAYG – it
> is only
> > > > there if you need it, but if you need it there is also no effort
> to add
> > > it
> > > > in as an optional dependency. If, because of this, there is a
> potential
> > > for
> > > > issues with modules or something I have not thought of, that
> will be
> > > > another thing to solve, but if so, I will find a way to address
> it.
> > > >
> > > > If the main concern with ‘size’ is data transfer, then looking
> at the
> > > > minified output size in HelloWorld is not really meaningful (or
> perhaps
> > > it
> > > > is better to say that it is only as meaningful as looking at the
> size
> > of
> > > an
> > > > uncompressed swf compared to normal deployment of a compressed
> swf). In
> > > any
> > > > real deployment the javascript should be served as gzipped. So I
> > compared
> > > > gzipped (‘normal’ compression) versions of HelloWorld.js between
> those
> > > with
> > > > the unused Language support methods (for int/uint and Vector)
> and their
> > > > dependencies vs. builds without. The support for all that
> functionality
> > > > comes in at under 3 Kb difference in the gzipped output. I
> personally
> > > don’t
> > > > think that would register as important in most cases. However,
> it is
> > > pretty
> > > > close to zero impact now if it is not used. In fact the
> HelloWorld
> > > > application is now about 55 bytes smaller than it was before, so
> I
> > > consider
> > > > it ‘carbon-netural’. And these are at the gzipped levels (it is
> also
> > > > slightly smaller when not gzipped, although it can sometimes be
> the
> > case
> > > > that the larger of 2 files compresses better than a smaller one,
> > > depending
> > > > on the content).
> > > >
> > > > As a general comment about size… in my experience over the last
> 10
> > years
> > > or
> > > > so, mostly in relation to Flex apps, size was most often not
> among the
> > > > highest priority issues. Sure, start-up time often was. But that
> is not
> > > > size per se. Often ‘size’ issues were first and foremost ‘asset
> size’
> > > > issues (embedded or separate). While I know overall that it
> remains
> > > > important, I personally think the growth in bandwidth and device
> memory
> > > in
> > > > general has outpaced the growth in the size of web apps even as
> the
> > world
> > > > has turned to mobile. In other words, I think we probably passed
> a
> > hurdle
> > > > point in the mobile side of things. Admittedly that is just
> > ‘perception’
> > > > and maybe there is data that shows I am quite wrong or your
> experience
> > on
> > > > specific client projects could be quite different. The point of
> me
> > > > explaining that was, however, to illustrate why I think ‘size’
> sits
> > > where I
> > > > think it does in general in terms of importance: I consider it
> to be
> > > behind
> > > > stability/reliability first which is followed by performance in
> > > performance
> > > > critical code. Overriding that general flow (which again, is
> just my
> > > > opinion), are whatever my client’s specific requirements are for
> any
> > > > particular project. In other words I am not sure how much of
> > HelloWorld’s
> > > > size is going to be an important deciding factor for someone to
> choose
> > to
> > > > use Royale. I think the ‘I got it to work!’ is the real kicker
> here.
> > This
> > > > paragraph was not to cause any conflict, and I already addressed
> the
> > > ‘size’
> > > > impact in the branch, so I’m not saying it wasn’t necessary to
> do that
> > > > (although I do suspect the same attention was not given to all
> other
> > > things
> > > > in the past that affected HelloWorld). It’s more to promote
> discussion
> > > and
> > > > thought in general. Trying to be all one aspect (small size) can
> > > compromise
> > > > other aspects (reliability or stability or compatibility, for
> example).
> > > And
> > > > trying to accommodate all aspects (reliability, small size,
> exceptional
> > > > performance) somehow very likely increases complexity because
> there is
> > a
> > > > need to accommodate the explicit decisions for trade-offs between
> > > competing
> > > > aspects. It would be good to have a guide of priorities based on
> the
> > > needs
> > > > of the user base (while I might have a strong opinion about what
> I
> > think
> > > is
> > > > important, I don’t assume that my views necessarily represent
> wider
> > user
> > > > needs, because I have not done research to support that – and
> it’s not
> > > > really a twitter poll kind of thing!). Anyhow I got off track
> there a
> > > bit…
> > > > back to Vector…
> > > >
> > > >
> > > >
> > > > *Performance.*
> > > >
> > > > No-one should expect a non-native Vector implementation to
> perform
> > faster
> > > > than native Array in javascript. Its main benefit is type
> safety, and
> > > that
> > > > is the reason it should be selected for use over Array. (In swf,
> native
> > > > numeric Vector types *are* selected for performance, but the
> other
> > Vector
> > > > types are also at least slightly slower than Array, so selecting
> them
> > is
> > > > based on the need for type safety)
> > > >
> > > > There are, however some ways to get 100% Array performance with
> this
> > > > implementation, and in a loop, for example it would be similar to
> > > avoiding
> > > > method calls (like push/pop) and only using index assignments
> that is
> > > > typical of performance optimization in swf.
> > > >
> > > > So these two methods provide almost Identical performance in js:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > *private function testArrayInt2(iterations:uint):Number{ var
> > > start:Date
> > > > = new Date(); var inst:Array = new Array(iterations);
> for
> > > (var
> > > > i:uint=0;i<iterations; i++) { inst[i] = i; }
> return new
> > > > Date().valueOf() - start.valueOf(); } /** * *
> > > > @royalesuppressvectorindexcheck true */ private function
> > > > testVectorInt2(iterations:uint):Number{ var start:Date = new
> > Date();
> > > > var inst:Vector.<uint> = new Vector.<uint>(iterations);
> for
> > > > (var i:uint=0;i<iterations; i++) { inst[i] = i; }
> > return
> > > > new Date().valueOf() - start.valueOf(); }*
> > > >
> > > > The doc comment on the 2nd method prevented the compiler from
> > generating
> > > an
> > > > index check wrapper around the ‘i’ in inst[i]
> > > >
> > > > The above 2 methods take around 5-7 ms for 500,000 iterations on
> my
> > > machine
> > > > (chrome/windows). This is quite a bit faster than the same
> methods in
> > the
> > > > swf (non-debug) build on my machine. The Vector constructor is
> also
> > doing
> > > > extra work in this case by setting all the 500,000 slots to
> numeric 0.
> > > But
> > > > on modern browsers it is using a fast native Array.fill method
> to do
> > > that,
> > > > so it’s probably more noticeable on IE11 which uses a for loop to
> > > > pre-populate the contents with numeric 0 values.
> > > >
> > > > For reference, the generated code for the second method above,
> looks
> > like
> > > > this:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > */** * * @royalesuppressvectorindexcheck true * @private *
> @param
> > > > {number} iterations * @return {number} */
> > > >
> > > >
> > >
> >
> flexUnitTests.language.LanguageTesterTestVectorPerf.prototype.flexUnitTests_language_LanguageTesterTestVectorPerf_testVectorInt2
> > > > = function(iterations) { var /** @type {Date} */ start = new
> Date();
> > > > var /** @type {Array.<number>} */ inst = new
> > > >
> (org.apache.royale.utils.Language.synthVector('uint'))(iterations);
> > for
> > > > (var /** @type {number} */ i = 0; i < iterations; i++) {
> inst[i] =
> > i;
> > > > } return new Date().valueOf() - start.valueOf(); };*
> > > >
> > > > The methods with type checking in them, like push, unshift etc
> will be
> > > > quite a lot slower though. This should not be a surprise. In
> swf, when
> > > you
> > > > look at something like Vector.<IBead> it can be up to 30% slower
> than
> > > Array
> > > > for methods like push, iirc at native level. In javascript it
> will be a
> > > lot
> > > > more. But in both cases it has type safety. And for small
> collection
> > > sizes
> > > > in non-performance sensitive code it is probably not going to
> make a
> > > > meaningul difference.
> > > >
> > > > Known limitations
> > > >
> > > > 1. myVectorInstance[‘constructor’] can be different
> between js
> > and
> > > > swf
> > > >
> > > > 2. There is some reliance on not obscuring the type from
> the
> > > compiler
> > > > for things to work correctly. Example:
> > > >
> > > > var myObscuredType:* = new Vector.<String>(20,true) // creates a
> fixed
> > > > Vector of length 20
> > > >
> > > > myObscuredType.length = 21; //should throw an error, but does
> not in
> > > > javascript.
> > > >
> > > > This will work as long as the compiler knows that the type with
> the
> > > length
> > > > setter is some type of Vector, otherwise not.
> > > >
> > > >
> > > >
> > > > *Performance tuning*
> > > >
> > > > *@royalesuppressvectorindexcheck*
> > > >
> > > > The above doc comment directive avoids checking for
> out-of-valid-range
> > > > index values on assignments. This is extremely desirable inside
> loops
> > > which
> > > > are usually constrained to the valid range in any case. There is
> a top
> > > > level compiler configuration setting for this, but local
> settings win
> > > > (turning off or on generally with true/false, or suppressing
> > specifically
> > > > for individual local variable names)
> > > >
> > > >
> > > >
> > > > Other options.
> > > >
> > > > The above one was obvious to me as an important tuning option. I
> > started
> > > > with adding another but pulled it out in favor of adding them
> based on
> > > > actual need.
> > > >
> > > > There are many options:
> > > >
> > > > Instance based: reducing type checking with a compiler-only
> generated
> > > > additional constructor parameter, triggered by some doc comment
> > > directive.
> > > > This could be in the form of adding in compiler generated
> alternatve
> > > calls
> > > > to things like ‘unsafePush’ and ‘unsafePop’ on instances, or
> perhaps
> > > > literal calls to Array.prototype.push.call(inst, pushItem),
> triggered
> > by
> > > > some doc comment directive
> > > >
> > > > Global changes:Adding some compiler define value that (along
> with:
> > > > ||goog.DEBUG) suppresses many runtime checks in the release
> Vector
> > > > implementation. This would allow a blanket approach to dialing
> runtime
> > > > safety down (or keeping them) in the release build. It would
> apply
> > across
> > > > all libraries and local project code.
> > > >
> > > > Some combinations of the above that allow sweeping optimizations
> with
> > > local
> > > > exceptions.
> > > >
> > > > Basically, this branch currently represents what I have reason to
> > believe
> > > > is a high conformance Vector implementation which should be the
> default
> > > as
> > > > it is an as3 core type. I think there are many options to scale
> things
> > > > back, but rather than assume what they should be, I’d prefer to
> hear
> > from
> > > > users and address *real* needs, so that we only end up with
> > configuration
> > > > options that matter.
> > > >
> > > >
> > > >
> > > > *Advantages of a single Vector implementation – the case for
> avoiding a
> > > > ‘vector emulation class’*
> > > >
> > > > ‘Language emulation’ is a foundational layer that is not in the
> same
> > > > category as ‘application framework’ where we can define things
> how we
> > > want.
> > > > Because the royale sdk includes both aspects inside ‘framework’
> (and
> > that
> > > > was obviously not the case for flex sdk in the past) it may be
> easy to
> > > > overlook that difference.
> > > >
> > > > Vector typing is a core part of AS3 language. Therefore it should
> > conform
> > > > and be reliable. Having multiple implementations for a core
> language
> > > > feature seems wrong and could easily lead to libraries of code
> that are
> > > > incompatible. Additionally, as pointed out earlier, Vector is
> more
> > like a
> > > > subclass factory (‘runtime’ generics) than a single class, so
> won’t be
> > > well
> > > > represented by a regular class implementation.
> > > >
> > > > Alex, I know you added support for a Vector emulation class
> approach to
> > > > meet the needs of someone asking for improved Vector support, in
> part
> > > > because we did not have someone who had volunteered to write our
> own. I
> > > did
> > > > that last part now. I am also suggesting that the emulation class
> > > approach
> > > > is not a good long term solution because of the above reasons.
> And the
> > > full
> > > > set of functionality is less than 3Kb in the gzipped output, so
> I’d
> > > suggest
> > > > that as long as I can add needs-based performance tuning options
> for
> > > those
> > > > who want them, the benefits of having a single conforming
> > implementation
> > > > which is performance scalable are better than the risks
> associated with
> > > > adding partially non-conforming ones. Therefore I’d like to ask
> if we
> > can
> > > > remove that functionality now that we have our own 'Vector' (I
> can do
> > the
> > > > work if you prefer as I know your focus is understandably on
> other
> > > things).
> > > >
> > > > *Future:*
> > > >
> > > > It will be easily possibly to alter the current implementation
> to use
> > es6
> > > > proxy which would likely provide the most reliable way to get
> full
> > Vector
> > > > conformance indistinguishable from flash. Es6 proxy is
> transparent for
> > > > Array:
> > > >
> > > > var p = new Proxy(new Array(), {});
> > > >
> > > > Array.isArray(p) // true
> > > >
> > > > This should allow trapping things like the length setter before
> it gets
> > > to
> > > > the underlying Array target, and doing checking for fixed ==
> true etc.
> > > The
> > > > same is true for numeric index-based assignment of values etc.
> > > >
> > > > es6 Proxy is kinda cool. At the moment IE11 is the only
> meaningful
> > target
> > > > that does not support this.
> > > >
> > > > I am only mentioning this here because I did think about this,
> and I
> > > > believe that the current implementation could be upgraded quite
> easily
> > to
> > > > use this approach if it makes sense (when IE11 is a distant
> memory –
> > > > perhaps sometime next year!).
> > > >
> > > >
> > > >
> > > > Phew, you made it! Well done.
> > > >
> > > > Feel free to share your thoughts or ask any questions you might
> have.
> > If
> > > > you have neither of those at this time, please still try to find
> time
> > to
> > > > test any large projects you have in the branch, and provide
> feedback or
> > > > share any concerns you might have after doing that.
> > > > thanks,
> > > > Greg
> > > >
> > > >
> > > > On Thu, May 23, 2019 at 7:55 PM Greg Dove <gr...@gmail.com>
> wrote:
> > > >
> > > > > Re XMLTest manualtest...
> > > > >
> > > > > Yep those were the ones I ported, Harbs. I think I got them
> all but
> > may
> > > > > have missed some. I added a bunch more as well. Hopefully
> these can
> > be
> > > > > easily migrated to what Josh has been working on.
> > > > >
> > > > >
> > > > > On Thu, 23 May 2019, 19:43 Harbs, <ha...@gmail.com>
> wrote:
> > > > >
> > > > >> As far as XML unit tests go, the starting point should be
> XMLTest in
> > > > >> manual tests. (Almost) every time I ran into an issue, I
> added it to
> > > > that
> > > > >> project.
> > > > >>
> > > > >> I think I might have been lax on the last few issues I fixed,
> so we
> > > > >> should probably go through the later XML commits and make
> sure we
> > have
> > > > >> tests for that.
> > > > >>
> > > > >> As far as Node goes, I think we probably need conditional Node
> > > > >> compilation to handle Node-specific (and browser specific)
> code in a
> > > > PAYG
> > > > >> way.
> > > > >>
> > > > >> To technically handle the parsing, something like
> > > > >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=FUUihStMfLg3KvkiVM24DfmOr2JY4lCV%2BX4rEdE%2FGso%3D&reserved=0
> >
> > > is
> > > > a
> > > > >> good starting point and something like this
> > > > >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0
> <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=Sv8hmktvAMktEP30faTxBZrUGuKOI2qArBCSGzqGWd4%3D&reserved=0
> >
> > > > >> might be useful to either use or modify.
> > > > >>
> > > > >> Harbs
> > > > >>
> > > > >> > On May 23, 2019, at 10:18 AM, Greg Dove <
> greg.dove@gmail.com>
> > > wrote:
> > > > >> >
> > > > >> > All, I started porting some adhoc XML tests to UnitTests and
> > > > eventually
> > > > >> > ended up spending quite a bit of time on addressing issues
> that
> > > arose
> > > > >> for
> > > > >> > XML before getting back to Vector stuff.
> > > > >> > I think XML probably needs many more unit tests before we
> get to
> > 1.0
> > > > >> > because it has an extensive api. I have not used royale
> with Node
> > > yet,
> > > > >> but
> > > > >> > XML also needs some thought about how to get it working on
> Node, I
> > > > >> assume.
> > > > >> > Because XML uses the browser's parser and Node does not
> have one
> > by
> > > > >> > default, then using the same code will need something to
> take the
> > > > place
> > > > >> of
> > > > >> > the browser's native parser for Node. There is a lib in npm
> that
> > > might
> > > > >> be
> > > > >> > useful for that, but I don't know how that might work with
> licence
> > > > etc.
> > > > >> > Anyhow, that is just an observation, I will focus on Vector
> in
> > this
> > > > >> > thread... I will post here late tomorrow local time with
> more
> > info,
> > > > and
> > > > >> > discussion points. I am keen to see this merged in, but
> also keen
> > to
> > > > get
> > > > >> > buy-in first.
> > > > >> >
> > > > >> >
> > > > >> > On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <
> > > > carlosrovira@apache.org
> > > > >> >
> > > > >> > wrote:
> > > > >> >
> > > > >> >> 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.dove@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.dove@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
> > > <aharui@adobe.com.invalid
> > > > >
> > > > >> >>>> wrote:
> > > > >> >>>>
> > > > >> >>>>> +1 to renaming the options to the positive.
> > > > >> >>>>>
> > > > >> >>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <
> joshtynjala@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.dove@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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628961027&sdata=vC7Sy%2BfGwJhbS8bR0Eo4wZBTNxsuEGCWXQ6nHceAk18%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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=NlTd48QGPtLVuoxX%2Fv4IO0ZZyz3CMgh7Gzllr3D%2BIoA%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%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=dwgAt0Rz%2Bt575HRIk97kPbtewGN4mSv8FbCQr6Skudg%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
> > > > >> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0
> > > > >> >>
> > > > >>
> > > > >>
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C6d2877e0e9a14986ba2708d6e2881e8b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636945471628971023&sdata=TUTQu7PlBt8iBBUzUY%2F4AFW2mtTtRj1Fiq2g3P5vQuw%3D&reserved=0
> >
>
>
>
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
Hi Alex, sorry it can take a while for me to reply at the moment... some
comments inline below...
On Sun, May 26, 2019 at 11:10 AM Alex Harui <ah...@adobe.com.invalid>
wrote:
> Hi Greg,
>
> Thanks for working through all of this. Better Vector handling is
> definitely a good thing for Royale.
>
I also believe so. In terms of my motivation for doing this work... I
actually have no imminent need for Vector, but I wanted to do something
concrete which I think is essential for 1.0.
I do have my own libraries and past client work from that use Vector, so I
see benefit in knowing that it will be easy to port to Royale and work
without any issues if I need to do that at any point (hopefully I will). I
also got to see how Vector was treated differently/specially when working
on AMF, and realized that we had no way to support it there correctly
because it is 'special' also in amf, so that was another motivation (again,
not for anything I actually need at the moment for myself or anyone else,
but because it is something else that is lacking for 1.0).
However, IMO, PAYG is more important and 3KB can be a full second or more
> on busy/slow/poor networks. As such, folks need to have choices. So as
> long as folks can choose Vector implementations we should be good.
>
> A couple of things here. Firstly, I really did not think I would need to
be this specific... but iirc it was actually 2990 bytes.
My first reaction to your scenario above would be: that network connection
speed is really *unusable* for anything on today's internet... and that is
a problem that should be addressed first, otherwise it does not matter
which development tech you plan to use, it will be a common problem,
royale, react... whatever.
I can't recall something from my last 10 years where 3KB would be
considered a driving force for an intervention that would (presumably) only
save a portion of that (and introduce future potential maintainability
risks). 3KB was less than a second on dialup over 20 years ago. Things have
changed dramatically in the last 5 years in particular. We are in a HD
streaming world now, with many countries supporting 4K streaming connection
speeds. And average speeds continue to grow globally at solid rates
year-on-year. 4G has impressive global coverage, and 5G is on the horizon.
I did mention this generally my earlier comments about bandwidth growth
outpacing growth in the size of apps. With your example are you
hypothesizing or do you have a real recent example in mind where this type
of thing was happening? If I was asked to classify the likelihood of the
scenario you described I would describe it as a few standard deviations
away from the center of the bell curve based on my own experience.
However I absolutely do agree with you that choice is important, I just
believe that performance most often will be more of a reason for the
decision to choose alternates (and it may mean adding 'size', not reducing
it).
And I think the choice should be explicit/obvious rather than having
something that is a lesser implementation of what it is actually supposed
to be. By this, I mean more application framework alternatives, instead of
supporting variations that represent non-conforming language classes. If
that approach is used, I think it will result in clearer, better quality,
more maintainable code. This is also a general approachI have observed
elsewhere.
Choosing Array is always an option in javascript and provides a zero
byte-weight option. I also plan to introduce some options for the numeric
types that represent best performance across both targets... but not as
'Vector' numeric types. The aim here would be to get faster than 'Vector as
Array' in javascript and it will be just a convenience approach to avoid
writing your own COMPILE::JS blocks with the native TypedArrays.
In terms of tweaking this Vector implementation's performance as further
options, I already explained I am happy to work on that based on actual
feedback for need. But I still think it requires caution and consideration
in terms of potential risks for people releasing libraries that could
expose non-conforming instances of Vectors (something that can never happen
in swf).
There are perhaps some possibilities for enhancing [ArrayElementType] with
a compiletime=true argument to get something more like what Harbs is after,
but that would only work for class members, not local vars. Perhaps there
are other simple ways to add 'compiletime' safety without going to full
blown generics support yet.
> Flex failed in some major vendors' customer-facing apps because of
> download times. I have spent the past years trying to make sure Royale
> does not repeat those mistakes.
>
>
I do want you to understand that I'm on the same team. And like you, I
don't want to repeat old mistakes too. But I also would like to see us
avoid possible new ones.
In the last 5 years or so, I have never really had a client spend much time
focusing on the size. Before that I think I was more aware of it. Anyhow,
it's not that it was never important at all, it's just that it was
relatively unimportant compared to other aspects. And apart from
remembering the size of flex apps in the past, I've seen the size of react
apps I worked on recently too.
I actually just looked at one of those. It is 8762KB minified and
compresses to 1293KB gzipped. The app does not compare directly, but it is
similar to Carlos' app in that it has many complex input rules and
sequences, however in a lot of ways Carlos' app is far more complex and has
a lot more remote API calls. However the final result from royale with
Carlos's app has a much, much lighter footprint than those numbers for
react. So Alex, I think the work you and others have put into avoiding
unneeded weight in the application framework has paid (and will continue to
pay) 'dividends' (as a metaphoric expression for anyone unfamiliar with
that).
But I do think of the language layer below the application framework layer
as 'different' and that it should be treated as if it has existing
specifications that are not free to reshape as we see fit (which it does,
directly or indirectly). The language is still actionscript, it's not
royalescript or jactionscript or something else. I've also spelt out a
number of the reasons why I have these views earlier. One thing I did not
mention was that my views also reflect my experience and observations with
another cross platform language. I have seen some cases, for example, where
over the course of iterative improvements, the use of native classes (the
example that springs to mind was for XML parsing) was removed from a
language level library and the whole feature was re-implemented in local
code because it was more desirable to achieve consistency across targets
than to have the best performing code on any one target. The IDE plugin for
that particular sdk has over 120K downloads in the one IDE I use most often
and it has a number of other IDEs supporting it with their own plugins etc.
So I have reason to believe it is popular, and I know it is disciplined at
the language level for a number of these shared target aspects. The
consistency therefore seems to be very important to its user base, more so
than the prospect of each language level feature 'being the smallest it can
be'. But beyond the core language it also has lots of scope for
accommodating differences. My exposure to this (and involvment with it in
the past) has also influenced my thinking. I try to avoid thinking "that's
them and not us" because that is a poor reason to ignore the learnings of
others. Much of my own knowledge and skills over the years is the result of
shared knowledge (royale and yourself included as a boost to that for which
I am grateful). Anyway, part of the thinking does come from awareness of
other things elsewhere, but I did pass it through my 'how does it relate to
royale' filter.
I have some comments on finer details, but let's see if we can agree on
> this higher-level issue first. We simply should offer people choices.
>
> Just repeating: I too am keen to offer choices and also to make it easy to
choose them. We only have different views over what those choices should
be. I would prefer them to be safer choices. I believe avoiding the
multiple Vector implementation approach will avoid future pitfalls and
possible developer confusion that could arise from the distribution of
inconsistent or non-conforming language level code. Neither of us can be
certain if those risks are real. But there is one way to avoid them for
sure (and yet still provide choices). That is essentially the crux of my
thinking. Do you think that logic is reasonable at the higher-level?
Beyond that, I did not obviously remove any emulationClass code in the
compiler and would not do so without your agreement, so nothing there has
changed.
Actually in the branch I think I changed something to pass qualified name
instead of basename somewhere, because base name would not be correct in
the general case. For that reason I don't think anybody was using that
feature yet, although I know you added it in response to a request from
Joshua Granick, as a way to address the Array-not-Vector issue. I do not
think it should be there now that we have something that we can call our
own, which is why I asked if we could remove it. Anyway, in terms of that
decision, can we agree to table it for now, merge the branch and maybe
continue this discussion later? I will go ahead and work on the other
'choices' I have in mind regardless, maybe when you see them you might
change how you think about things (or not, it is the apache way).
> Thanks,
> -Alex
>
> On 5/25/19, 2:45 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Hi Carlos, thanks for your feedback. In terms of PAYG, I just have a
> sense
> that at the language level, the 'default' should be that it *works* as
> per
> design.
> If I take the example of Vector... then numeric Vector types will not
> run
> faster in javascript. Using all the method calls will have a
> substantial
> impact compared to using a normal Array. But code should 'work' the
> same
> across targets.
> I do have some ideas for application framework classes outside
> 'language'/Vector that would provide target-agnostic fast regular class
> implementations for numeric typed Arrays, and I hope to work on that
> soon
> as well, which takes more advantage of the optimized native options on
> each
> target (Vector in swf, TypedArray in javascript). But to achieve that
> it
> will likely be 'always fixed length' in this case, I will see if it
> seems
> worth trying to be able to toggle that, or maybe it can be a bead or
> opt-in
> support to get that functionality. But that should provide a good
> option
> for developers seeking to get the best performance for numeric
> collections.
> I expect to work on this during June.
> Or developers can of course always choose to implement their own custom
> performance code in COMPILE::JS / COMPILE::SWF variations, which is
> always
> an option.
>
>
> Hi Piotr, sorry about that email formatting issue. Thanks for your
> follow
> up on this.
> Here is a paste of that part, which includes the code.
>
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdPWy&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212062967&sdata=17ke54YZccaT%2BCQNKJLeihpTrSb2Nf4JB37o6c4ozGs%3D&reserved=0
>
> Also, if you want to see the tests for Vector, you can see them 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&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=GbM8oh6UkKpVE2HsdKwHgt6RgRJ9iNWIlCAhiubmHTk%3D&reserved=0
>
>
> You should see large parts of that series of tests fail outside the
> branch, and in some cases there were compiler errors too iirc (or
> maybe I
> am confusing some compiler fixes I did for other things, can't be sure
> now)
>
>
>
> On Sun, May 26, 2019 at 4:58 AM Carlos Rovira <carlosrovira@apache.org
> >
> wrote:
>
> > Hi!
> >
> > Read it! :), was long but I think this emails are needed since it
> brings
> > many thoughts that only the developer knows and otherwise would end
> never
> > known by the rest of the community. So Great!
> >
> > Greg, first, many thanks for working on this. I think we get other
> point
> > solved, and I think not only Vector, but many other fixes and things
> coming
> > in your branch.
> >
> > For my part, as you said, the branch is tested against my real
> project,
> > that I think is a very good way to test against lots of working
> code. So
> > for my is ok to merge, not only cause it does not brake anything,
> but cause
> > it's a big step forward.
> >
> > Since it brings things we didn't have before like Vector, is good to
> bring
> > this. Then we can continue iterating to add missed things like AMF
> support
> > or to evolve to other state or even change internal things if other
> check
> > and see ways of enhancements.
> >
> > About the Vector implementation. My opinion is that I think as you
> that
> > Vector is an intrinsic part of AS3, so better to have an
> implementation to
> > complete AS3 in Royale. About having multiple implementations, I
> think that
> > could be good in the future if things can be done that way, but
> better
> > start from this starting point and see what happens in next
> months-years.
> > IOW, better have a real implementation now that a potentially one
> that
> > still is not here. We need to see the goal and approach to it
> progressively
> > or we end getting nothing since the goal is a huge one not easy to
> reach.
> >
> > For me the 3kb is totally normal, and as well a great achievement of
> your
> > implementation.
> > I must say that my way of thinking in Royale is to be totally
> aligned with
> > concepts like PAYG, but sometimes we need to break rules when the
> goal
> > demand it, or we can end trying to apply the same principle to all
> things,
> > when sometimes is not the best. So this is importante, rules are
> really
> > good, but we need to always put behind a layer of human thinking
> about what
> > we are trying to accomplish
> >
> > Thanks Greg for reaching another important milestone! Amazing work!
> :)
> >
> > Carlos
> >
> > PD: Piotr, about gmail cutting the email, I'm using gmail and get to
> read
> > it completely, maybe could be a problem of gmail in mobile? I'm
> reading on
> > gmail desktop. The only problem I had was reading posted source
> code, but
> > since it was tiny, I could finally read it...
> >
> >
> >
> >
> >
> > El sáb., 25 may. 2019 a las 15:37, Piotr Zarzycki (<
> > piotrzarzycki21@gmail.com>) escribió:
> >
> > > Hi Greg,
> > >
> > > Could you please post the code from this email in the
> paste.apache.org -
> > > right now is unreadable in my Gmail account.
> > >
> > > Thanks,
> > > Piotr
> > >
> > > On Sat, May 25, 2019, 4:51 AM Greg Dove <gr...@gmail.com>
> wrote:
> > >
> > > > OK, At the risk of making what follows even longer... a warning:
> *this
> > > is a
> > > > long read*. It might veer off topic in one or two places, but it
> is
> > > mostly
> > > > about why, and how Vector is implemented the way it is in the
> branch.
> > > > Basically I would like to merge this branch into develop as soon
> as
> > > > possible, i actually think it is ready as is, but I am keen to
> get
> > other
> > > > input before I do.
> > > > Read it if you're interested. If you're not interested in
> reading it
> > then
> > > > please try the branch on any 'real' projects that you have in
> play.
> > > Carlos
> > > > has tested against his, and there are no issues, but it would be
> good
> > to
> > > > get wider input.
> > > >
> > > > now to the textual onslaught:
> > > >
> > > >
> > > > *Vector*
> > > >
> > > > One of the things I did before I worked on this Vector
> implementation
> > was
> > > > to detach myself from ‘how I use Vector when I code’, to take a
> step
> > back
> > > > and challenge myself to rethink how I thought about it in
> general.
> > > >
> > > > Vector is *special*. Vector is not *a class* in a typical sense.
> It is
> > > the
> > > > closest thing that as3 has to generics which, when used at a
> class
> > > level, I
> > > > like to think of as the ability to generate multiple class
> variations
> > > from
> > > > a single class definition (that is just the way I think of
> them). So,
> > at
> > > > some level Vector could be considered as an infinite set of
> distinct
> > > > classes, based on an infinite set of possible specified element
> types
> > > > (whatever you see between the angle brackets in code). It is not
> > actually
> > > > implemented natively in AVM this way iiuc, but that is the
> outward
> > > > appearance, and that is also the behaviour it has when using type
> > > checking
> > > > in as3.
> > > >
> > > > Aside from the runtime typesafe behaviour, Vector’s strong
> typing means
> > > > there is additional compile time support and, related, the
> possibility
> > of
> > > > extra IDE support, both of which help the developer.
> > > >
> > > > Vector ‘types’ are also final ‘classes’ enforced by the
> compiler, so
> > > cannot
> > > > be extended.
> > > >
> > > > Additionally, on looking closer, there are some other quirky
> rules for
> > > > runtime typing behaviour. These are related to the
> implementation in
> > AVM.
> > > > The 3 Vector types for Vector.<int>, Vector.<uint>, and
> Vector.<Number>
> > > are
> > > > individual base types, and then there is a 4th base type,
> Vector.<*>
> > > which
> > > > serves as the ‘base class’ of all other Vector ‘subclasses’. The
> 3
> > > numeric
> > > > types are faster than Array, and I expect this was the reason
> for the
> > > > separation, because these are used in a lot of other flash apis,
> > > > particularly for swapping with byte level data and things like
> > BitmapData
> > > > etc. The others are more simply for the strong typing aspects,
> because
> > > > (perhaps less so with Boolean and String at a guess) they are
> somewhat
> > > > slower than Array in AVM, because of the overhead of runtime
> > typechecking
> > > > and coercions etc. So the main selling points for choosing a
> Vector in
> > > > flash were a) compile time and runtime type safety and b) faster
> > > > performance for the 3 numeric Vector types.
> > > >
> > > > One implication of these ‘rules’ means that to check if
> *something* is
> > a
> > > > Vector of any type in swf, I need to do (mything is Vector.<int>
> ||
> > > myThing
> > > > is Vector.<uint> || myThing is Vector.<Number> || myThing is
> > Vector.<*>)
> > > or
> > > > use reflection (which is slower).
> > > >
> > > > The above implies that, for language conformance (considered as
> > > conformance
> > > > with as3 documentation/spec and the behaviour of the reference
> > > > implementation that we have for any ‘unknowns’) in an emulation,
> a
> > > regular
> > > > single as3 class implementation would not create a result that is
> > > > consistent with the spec in terms of its representation of
> typing, and
> > > its
> > > > behaviour when using type checking.
> > > >
> > > > I tried to take all of these things into consideration.
> > > >
> > > >
> > > >
> > > > *How is it implemented in the branch?*
> > > >
> > > > Vector is implemented using the lightweight ‘synthType’ approach
> I
> > added
> > > > previously to support for int and uint types as ‘classes’. This
> > provides
> > > a
> > > > light integration for ‘is’ and ‘as’ checks, but in javascript
> itself a
> > > > Vector instance is simply a tagged native javascript Array
> instance
> > (i.e.
> > > > an Array with something that identifies it as being ‘not a
> regular
> > > Array’).
> > > > The Array methods are enhanced at the instance level to support
> the
> > type
> > > > coercions that take place in an actionscript Vector. Using Array
> makes
> > > > sense because Vector instances are essentially typed Arrays. But
> it is
> > > not
> > > > possible to extend Array in javascript and have things work
> properly
> > (it
> > > is
> > > > possible to use a different approach with es6 Proxy, but that is
> not
> > > > available in IE11).
> > > >
> > > > This implementation also means that a ‘Vector’ instance should
> have
> > > > functionality that works mostly as expected if it is passed
> directly to
> > > a 3
> > > > rd party native javascript library that is expecting an Array
> instance.
> > > It
> > > > will not support errors when changing the length if the Vector
> instance
> > > is
> > > > ‘fixed’ length, for example but otherwise it should function
> much the
> > > same
> > > > as a regular Array in the 3rd party code.
> > > >
> > > > The ‘synthType’ approach can be used because Vector types are
> final, so
> > > it
> > > > does not need to conform to a regular Royale class definition
> that can
> > be
> > > > extended and can be much ‘lighter’. As with int and uint
> ‘classes’, no
> > > > Vector constructor exists until the first one is requested.
> There is
> > one
> > > > internal private class in Language that provides most of the
> > > functionality
> > > > for Vector, and element coercion functions are generated
> specifically
> > for
> > > > each Vector ‘subtype’. Overall, it behaves more like a subclass
> > ‘factory’
> > > > with each individual type’s constructor being created on demand
> and
> > > cached
> > > > for future use.
> > > >
> > > > Reflection and serialization support have not been added yet,
> but I
> > > > certainly had these in mind also with this approach. I just
> wanted to
> > > reach
> > > > a sensible intermediate point for now, and then add those in
> later.
> > > >
> > > > In summary, the Vector implementation in the branch provides the
> > > following:
> > > >
> > > > -distinct types (conforming in terms of type checking) for each
> Vector
> > > > subtype
> > > >
> > > > -lightweight integration with Language ‘is’ and ‘as’ support
> > > >
> > > > -each Vector subtype has a unique constructor generated the
> first time
> > it
> > > > is requested, the constructor does not exist prior to that.
> > > >
> > > > -expected to be compatible with 3rd party native javascript that
> > expects
> > > a
> > > > regular javascript Array
> > > >
> > > > -serialization (amf) and reflection are not yet supported but
> were
> > > > considered, and that is planned as next steps.
> > > >
> > > > As at the time of writing, the current implementation is
> supported by
> > 300
> > > > Vector-specific assertions that run side-by-side between
> javascript and
> > > swf
> > > > in the manualtest UnitTests project. Apart from the differences
> created
> > > by
> > > > explicitly switching off some type safety checks with
> > > > @suppressvectorindexchecking, there is only one verifiable
> difference
> > in
> > > > these tests between swf and javsacript. Probably there are things
> > outside
> > > > the test coverage that might need addressing still, but I think
> it’s a
> > > > pretty good start.
> > > >
> > > > These tests should be easily ported to framework level unit tests
> > > > (RoyaleUnit) as the same approach has been used to add FlexUnit
> tests
> > in
> > > > the past. Testing/Development is primarily in Chrome on windows,
> but
> > the
> > > > same tests were subsequently verified on IE11, Edge, Opera and
> Firefox
> > on
> > > > windows.
> > > >
> > > > *Implementation Info*
> > > >
> > > > *More quirks*
> > > >
> > > > A ‘fixed == true’ Vector cannot have its length changed. This
> means
> > that
> > > > changes via the length setter and the mutation methods (push,
> pop,
> > shift,
> > > > unshift etc) all throw errors if used when a Vector is ‘fixed ==
> true’.
> > > > But… splice method also can change length. And in AVM this works
> even
> > > with
> > > > a fixed length Vector, which might possibly be a bug but is one
> that is
> > > > matched in the implementation to conform with flash.
> > > >
> > > > *Size impact.*
> > > >
> > > > Alex was concerned with size impact for HelloWorld because the
> beads
> > were
> > > > using a Vector.<IBead> type in javascript in one of the
> application
> > > > framework base classes. But the requirement was for that to
> simply to
> > be
> > > an
> > > > Array in javascript, the compiler was only achieving that by
> default
> > > > because there was no real Vector implementation. So I did a
> couple of
> > > > things here. Firstly I changed the application framework code to
> > reflect
> > > > the different requirement for javascript. Secondly, I added some
> doc
> > > > comment directives to suppress exporting on public members. Then
> I
> > added
> > > > this to the Language methods that are for compiler-generated
> Vector
> > (and
> > > > int and uint) support so that they are eligible for dead code
> > elimination
> > > > if not used. This effectively means that it is fully PAYG – it
> is only
> > > > there if you need it, but if you need it there is also no effort
> to add
> > > it
> > > > in as an optional dependency. If, because of this, there is a
> potential
> > > for
> > > > issues with modules or something I have not thought of, that
> will be
> > > > another thing to solve, but if so, I will find a way to address
> it.
> > > >
> > > > If the main concern with ‘size’ is data transfer, then looking
> at the
> > > > minified output size in HelloWorld is not really meaningful (or
> perhaps
> > > it
> > > > is better to say that it is only as meaningful as looking at the
> size
> > of
> > > an
> > > > uncompressed swf compared to normal deployment of a compressed
> swf). In
> > > any
> > > > real deployment the javascript should be served as gzipped. So I
> > compared
> > > > gzipped (‘normal’ compression) versions of HelloWorld.js between
> those
> > > with
> > > > the unused Language support methods (for int/uint and Vector)
> and their
> > > > dependencies vs. builds without. The support for all that
> functionality
> > > > comes in at under 3 Kb difference in the gzipped output. I
> personally
> > > don’t
> > > > think that would register as important in most cases. However,
> it is
> > > pretty
> > > > close to zero impact now if it is not used. In fact the
> HelloWorld
> > > > application is now about 55 bytes smaller than it was before, so
> I
> > > consider
> > > > it ‘carbon-netural’. And these are at the gzipped levels (it is
> also
> > > > slightly smaller when not gzipped, although it can sometimes be
> the
> > case
> > > > that the larger of 2 files compresses better than a smaller one,
> > > depending
> > > > on the content).
> > > >
> > > > As a general comment about size… in my experience over the last
> 10
> > years
> > > or
> > > > so, mostly in relation to Flex apps, size was most often not
> among the
> > > > highest priority issues. Sure, start-up time often was. But that
> is not
> > > > size per se. Often ‘size’ issues were first and foremost ‘asset
> size’
> > > > issues (embedded or separate). While I know overall that it
> remains
> > > > important, I personally think the growth in bandwidth and device
> memory
> > > in
> > > > general has outpaced the growth in the size of web apps even as
> the
> > world
> > > > has turned to mobile. In other words, I think we probably passed
> a
> > hurdle
> > > > point in the mobile side of things. Admittedly that is just
> > ‘perception’
> > > > and maybe there is data that shows I am quite wrong or your
> experience
> > on
> > > > specific client projects could be quite different. The point of
> me
> > > > explaining that was, however, to illustrate why I think ‘size’
> sits
> > > where I
> > > > think it does in general in terms of importance: I consider it
> to be
> > > behind
> > > > stability/reliability first which is followed by performance in
> > > performance
> > > > critical code. Overriding that general flow (which again, is
> just my
> > > > opinion), are whatever my client’s specific requirements are for
> any
> > > > particular project. In other words I am not sure how much of
> > HelloWorld’s
> > > > size is going to be an important deciding factor for someone to
> choose
> > to
> > > > use Royale. I think the ‘I got it to work!’ is the real kicker
> here.
> > This
> > > > paragraph was not to cause any conflict, and I already addressed
> the
> > > ‘size’
> > > > impact in the branch, so I’m not saying it wasn’t necessary to
> do that
> > > > (although I do suspect the same attention was not given to all
> other
> > > things
> > > > in the past that affected HelloWorld). It’s more to promote
> discussion
> > > and
> > > > thought in general. Trying to be all one aspect (small size) can
> > > compromise
> > > > other aspects (reliability or stability or compatibility, for
> example).
> > > And
> > > > trying to accommodate all aspects (reliability, small size,
> exceptional
> > > > performance) somehow very likely increases complexity because
> there is
> > a
> > > > need to accommodate the explicit decisions for trade-offs between
> > > competing
> > > > aspects. It would be good to have a guide of priorities based on
> the
> > > needs
> > > > of the user base (while I might have a strong opinion about what
> I
> > think
> > > is
> > > > important, I don’t assume that my views necessarily represent
> wider
> > user
> > > > needs, because I have not done research to support that – and
> it’s not
> > > > really a twitter poll kind of thing!). Anyhow I got off track
> there a
> > > bit…
> > > > back to Vector…
> > > >
> > > >
> > > >
> > > > *Performance.*
> > > >
> > > > No-one should expect a non-native Vector implementation to
> perform
> > faster
> > > > than native Array in javascript. Its main benefit is type
> safety, and
> > > that
> > > > is the reason it should be selected for use over Array. (In swf,
> native
> > > > numeric Vector types *are* selected for performance, but the
> other
> > Vector
> > > > types are also at least slightly slower than Array, so selecting
> them
> > is
> > > > based on the need for type safety)
> > > >
> > > > There are, however some ways to get 100% Array performance with
> this
> > > > implementation, and in a loop, for example it would be similar to
> > > avoiding
> > > > method calls (like push/pop) and only using index assignments
> that is
> > > > typical of performance optimization in swf.
> > > >
> > > > So these two methods provide almost Identical performance in js:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > *private function testArrayInt2(iterations:uint):Number{ var
> > > start:Date
> > > > = new Date(); var inst:Array = new Array(iterations);
> for
> > > (var
> > > > i:uint=0;i<iterations; i++) { inst[i] = i; }
> return new
> > > > Date().valueOf() - start.valueOf(); } /** * *
> > > > @royalesuppressvectorindexcheck true */ private function
> > > > testVectorInt2(iterations:uint):Number{ var start:Date = new
> > Date();
> > > > var inst:Vector.<uint> = new Vector.<uint>(iterations);
> for
> > > > (var i:uint=0;i<iterations; i++) { inst[i] = i; }
> > return
> > > > new Date().valueOf() - start.valueOf(); }*
> > > >
> > > > The doc comment on the 2nd method prevented the compiler from
> > generating
> > > an
> > > > index check wrapper around the ‘i’ in inst[i]
> > > >
> > > > The above 2 methods take around 5-7 ms for 500,000 iterations on
> my
> > > machine
> > > > (chrome/windows). This is quite a bit faster than the same
> methods in
> > the
> > > > swf (non-debug) build on my machine. The Vector constructor is
> also
> > doing
> > > > extra work in this case by setting all the 500,000 slots to
> numeric 0.
> > > But
> > > > on modern browsers it is using a fast native Array.fill method
> to do
> > > that,
> > > > so it’s probably more noticeable on IE11 which uses a for loop to
> > > > pre-populate the contents with numeric 0 values.
> > > >
> > > > For reference, the generated code for the second method above,
> looks
> > like
> > > > this:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > */** * * @royalesuppressvectorindexcheck true * @private *
> @param
> > > > {number} iterations * @return {number} */
> > > >
> > > >
> > >
> >
> flexUnitTests.language.LanguageTesterTestVectorPerf.prototype.flexUnitTests_language_LanguageTesterTestVectorPerf_testVectorInt2
> > > > = function(iterations) { var /** @type {Date} */ start = new
> Date();
> > > > var /** @type {Array.<number>} */ inst = new
> > > >
> (org.apache.royale.utils.Language.synthVector('uint'))(iterations);
> > for
> > > > (var /** @type {number} */ i = 0; i < iterations; i++) {
> inst[i] =
> > i;
> > > > } return new Date().valueOf() - start.valueOf(); };*
> > > >
> > > > The methods with type checking in them, like push, unshift etc
> will be
> > > > quite a lot slower though. This should not be a surprise. In
> swf, when
> > > you
> > > > look at something like Vector.<IBead> it can be up to 30% slower
> than
> > > Array
> > > > for methods like push, iirc at native level. In javascript it
> will be a
> > > lot
> > > > more. But in both cases it has type safety. And for small
> collection
> > > sizes
> > > > in non-performance sensitive code it is probably not going to
> make a
> > > > meaningul difference.
> > > >
> > > > Known limitations
> > > >
> > > > 1. myVectorInstance[‘constructor’] can be different
> between js
> > and
> > > > swf
> > > >
> > > > 2. There is some reliance on not obscuring the type from
> the
> > > compiler
> > > > for things to work correctly. Example:
> > > >
> > > > var myObscuredType:* = new Vector.<String>(20,true) // creates a
> fixed
> > > > Vector of length 20
> > > >
> > > > myObscuredType.length = 21; //should throw an error, but does
> not in
> > > > javascript.
> > > >
> > > > This will work as long as the compiler knows that the type with
> the
> > > length
> > > > setter is some type of Vector, otherwise not.
> > > >
> > > >
> > > >
> > > > *Performance tuning*
> > > >
> > > > *@royalesuppressvectorindexcheck*
> > > >
> > > > The above doc comment directive avoids checking for
> out-of-valid-range
> > > > index values on assignments. This is extremely desirable inside
> loops
> > > which
> > > > are usually constrained to the valid range in any case. There is
> a top
> > > > level compiler configuration setting for this, but local
> settings win
> > > > (turning off or on generally with true/false, or suppressing
> > specifically
> > > > for individual local variable names)
> > > >
> > > >
> > > >
> > > > Other options.
> > > >
> > > > The above one was obvious to me as an important tuning option. I
> > started
> > > > with adding another but pulled it out in favor of adding them
> based on
> > > > actual need.
> > > >
> > > > There are many options:
> > > >
> > > > Instance based: reducing type checking with a compiler-only
> generated
> > > > additional constructor parameter, triggered by some doc comment
> > > directive.
> > > > This could be in the form of adding in compiler generated
> alternatve
> > > calls
> > > > to things like ‘unsafePush’ and ‘unsafePop’ on instances, or
> perhaps
> > > > literal calls to Array.prototype.push.call(inst, pushItem),
> triggered
> > by
> > > > some doc comment directive
> > > >
> > > > Global changes:Adding some compiler define value that (along
> with:
> > > > ||goog.DEBUG) suppresses many runtime checks in the release
> Vector
> > > > implementation. This would allow a blanket approach to dialing
> runtime
> > > > safety down (or keeping them) in the release build. It would
> apply
> > across
> > > > all libraries and local project code.
> > > >
> > > > Some combinations of the above that allow sweeping optimizations
> with
> > > local
> > > > exceptions.
> > > >
> > > > Basically, this branch currently represents what I have reason to
> > believe
> > > > is a high conformance Vector implementation which should be the
> default
> > > as
> > > > it is an as3 core type. I think there are many options to scale
> things
> > > > back, but rather than assume what they should be, I’d prefer to
> hear
> > from
> > > > users and address *real* needs, so that we only end up with
> > configuration
> > > > options that matter.
> > > >
> > > >
> > > >
> > > > *Advantages of a single Vector implementation – the case for
> avoiding a
> > > > ‘vector emulation class’*
> > > >
> > > > ‘Language emulation’ is a foundational layer that is not in the
> same
> > > > category as ‘application framework’ where we can define things
> how we
> > > want.
> > > > Because the royale sdk includes both aspects inside ‘framework’
> (and
> > that
> > > > was obviously not the case for flex sdk in the past) it may be
> easy to
> > > > overlook that difference.
> > > >
> > > > Vector typing is a core part of AS3 language. Therefore it should
> > conform
> > > > and be reliable. Having multiple implementations for a core
> language
> > > > feature seems wrong and could easily lead to libraries of code
> that are
> > > > incompatible. Additionally, as pointed out earlier, Vector is
> more
> > like a
> > > > subclass factory (‘runtime’ generics) than a single class, so
> won’t be
> > > well
> > > > represented by a regular class implementation.
> > > >
> > > > Alex, I know you added support for a Vector emulation class
> approach to
> > > > meet the needs of someone asking for improved Vector support, in
> part
> > > > because we did not have someone who had volunteered to write our
> own. I
> > > did
> > > > that last part now. I am also suggesting that the emulation class
> > > approach
> > > > is not a good long term solution because of the above reasons.
> And the
> > > full
> > > > set of functionality is less than 3Kb in the gzipped output, so
> I’d
> > > suggest
> > > > that as long as I can add needs-based performance tuning options
> for
> > > those
> > > > who want them, the benefits of having a single conforming
> > implementation
> > > > which is performance scalable are better than the risks
> associated with
> > > > adding partially non-conforming ones. Therefore I’d like to ask
> if we
> > can
> > > > remove that functionality now that we have our own 'Vector' (I
> can do
> > the
> > > > work if you prefer as I know your focus is understandably on
> other
> > > things).
> > > >
> > > > *Future:*
> > > >
> > > > It will be easily possibly to alter the current implementation
> to use
> > es6
> > > > proxy which would likely provide the most reliable way to get
> full
> > Vector
> > > > conformance indistinguishable from flash. Es6 proxy is
> transparent for
> > > > Array:
> > > >
> > > > var p = new Proxy(new Array(), {});
> > > >
> > > > Array.isArray(p) // true
> > > >
> > > > This should allow trapping things like the length setter before
> it gets
> > > to
> > > > the underlying Array target, and doing checking for fixed ==
> true etc.
> > > The
> > > > same is true for numeric index-based assignment of values etc.
> > > >
> > > > es6 Proxy is kinda cool. At the moment IE11 is the only
> meaningful
> > target
> > > > that does not support this.
> > > >
> > > > I am only mentioning this here because I did think about this,
> and I
> > > > believe that the current implementation could be upgraded quite
> easily
> > to
> > > > use this approach if it makes sense (when IE11 is a distant
> memory –
> > > > perhaps sometime next year!).
> > > >
> > > >
> > > >
> > > > Phew, you made it! Well done.
> > > >
> > > > Feel free to share your thoughts or ask any questions you might
> have.
> > If
> > > > you have neither of those at this time, please still try to find
> time
> > to
> > > > test any large projects you have in the branch, and provide
> feedback or
> > > > share any concerns you might have after doing that.
> > > > thanks,
> > > > Greg
> > > >
> > > >
> > > > On Thu, May 23, 2019 at 7:55 PM Greg Dove <gr...@gmail.com>
> wrote:
> > > >
> > > > > Re XMLTest manualtest...
> > > > >
> > > > > Yep those were the ones I ported, Harbs. I think I got them
> all but
> > may
> > > > > have missed some. I added a bunch more as well. Hopefully
> these can
> > be
> > > > > easily migrated to what Josh has been working on.
> > > > >
> > > > >
> > > > > On Thu, 23 May 2019, 19:43 Harbs, <ha...@gmail.com>
> wrote:
> > > > >
> > > > >> As far as XML unit tests go, the starting point should be
> XMLTest in
> > > > >> manual tests. (Almost) every time I ran into an issue, I
> added it to
> > > > that
> > > > >> project.
> > > > >>
> > > > >> I think I might have been lax on the last few issues I fixed,
> so we
> > > > >> should probably go through the later XML commits and make
> sure we
> > have
> > > > >> tests for that.
> > > > >>
> > > > >> As far as Node goes, I think we probably need conditional Node
> > > > >> compilation to handle Node-specific (and browser specific)
> code in a
> > > > PAYG
> > > > >> way.
> > > > >>
> > > > >> To technically handle the parsing, something like
> > > > >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=5Rl9DZfo3zo%2Bk1q3x%2FygT4HehZ3IAkC5VGRHbKZ8Fbo%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=5Rl9DZfo3zo%2Bk1q3x%2FygT4HehZ3IAkC5VGRHbKZ8Fbo%3D&reserved=0
> >
> > > is
> > > > a
> > > > >> good starting point and something like this
> > > > >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=TUTK%2BrNRsyS96dBdSDczi8qpEfTnhi4bgE5WmXORAnE%3D&reserved=0
> <
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=TUTK%2BrNRsyS96dBdSDczi8qpEfTnhi4bgE5WmXORAnE%3D&reserved=0
> >
> > > > >> might be useful to either use or modify.
> > > > >>
> > > > >> Harbs
> > > > >>
> > > > >> > On May 23, 2019, at 10:18 AM, Greg Dove <
> greg.dove@gmail.com>
> > > wrote:
> > > > >> >
> > > > >> > All, I started porting some adhoc XML tests to UnitTests and
> > > > eventually
> > > > >> > ended up spending quite a bit of time on addressing issues
> that
> > > arose
> > > > >> for
> > > > >> > XML before getting back to Vector stuff.
> > > > >> > I think XML probably needs many more unit tests before we
> get to
> > 1.0
> > > > >> > because it has an extensive api. I have not used royale
> with Node
> > > yet,
> > > > >> but
> > > > >> > XML also needs some thought about how to get it working on
> Node, I
> > > > >> assume.
> > > > >> > Because XML uses the browser's parser and Node does not
> have one
> > by
> > > > >> > default, then using the same code will need something to
> take the
> > > > place
> > > > >> of
> > > > >> > the browser's native parser for Node. There is a lib in npm
> that
> > > might
> > > > >> be
> > > > >> > useful for that, but I don't know how that might work with
> licence
> > > > etc.
> > > > >> > Anyhow, that is just an observation, I will focus on Vector
> in
> > this
> > > > >> > thread... I will post here late tomorrow local time with
> more
> > info,
> > > > and
> > > > >> > discussion points. I am keen to see this merged in, but
> also keen
> > to
> > > > get
> > > > >> > buy-in first.
> > > > >> >
> > > > >> >
> > > > >> > On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <
> > > > carlosrovira@apache.org
> > > > >> >
> > > > >> > wrote:
> > > > >> >
> > > > >> >> 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.dove@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.dove@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
> > > <aharui@adobe.com.invalid
> > > > >
> > > > >> >>>> wrote:
> > > > >> >>>>
> > > > >> >>>>> +1 to renaming the options to the positive.
> > > > >> >>>>>
> > > > >> >>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <
> joshtynjala@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.dove@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%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=FgEQxhJYmuPRHJCp%2BU252ksKsI86IzXXC42N1V98sK8%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%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=0YKmOa48l7mIYYmuA6bJ%2FGQYDEd%2BMutJvSQp9k0sGyI%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%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=X8FK2azZSpsIHBZZCzfww4GAxxpOIeznBz7VOBr8WTg%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
> > > > >> >>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=E6W9Pr%2FN8qCsgSOcyOyT9gnk5rq5fEtKQJW4Qb6UuxQ%3D&reserved=0
> > > > >> >>
> > > > >>
> > > > >>
> > > >
> > >
> >
> >
> > --
> > Carlos Rovira
> >
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=E6W9Pr%2FN8qCsgSOcyOyT9gnk5rq5fEtKQJW4Qb6UuxQ%3D&reserved=0
> >
>
>
>
Re: Language improvements
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi Greg,
Thanks for working through all of this. Better Vector handling is definitely a good thing for Royale.
However, IMO, PAYG is more important and 3KB can be a full second or more on busy/slow/poor networks. As such, folks need to have choices. So as long as folks can choose Vector implementations we should be good.
Flex failed in some major vendors' customer-facing apps because of download times. I have spent the past years trying to make sure Royale does not repeat those mistakes.
I have some comments on finer details, but let's see if we can agree on this higher-level issue first. We simply should offer people choices.
Thanks,
-Alex
On 5/25/19, 2:45 PM, "Greg Dove" <gr...@gmail.com> wrote:
Hi Carlos, thanks for your feedback. In terms of PAYG, I just have a sense
that at the language level, the 'default' should be that it *works* as per
design.
If I take the example of Vector... then numeric Vector types will not run
faster in javascript. Using all the method calls will have a substantial
impact compared to using a normal Array. But code should 'work' the same
across targets.
I do have some ideas for application framework classes outside
'language'/Vector that would provide target-agnostic fast regular class
implementations for numeric typed Arrays, and I hope to work on that soon
as well, which takes more advantage of the optimized native options on each
target (Vector in swf, TypedArray in javascript). But to achieve that it
will likely be 'always fixed length' in this case, I will see if it seems
worth trying to be able to toggle that, or maybe it can be a bead or opt-in
support to get that functionality. But that should provide a good option
for developers seeking to get the best performance for numeric collections.
I expect to work on this during June.
Or developers can of course always choose to implement their own custom
performance code in COMPILE::JS / COMPILE::SWF variations, which is always
an option.
Hi Piotr, sorry about that email formatting issue. Thanks for your follow
up on this.
Here is a paste of that part, which includes the code.
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdPWy&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212062967&sdata=17ke54YZccaT%2BCQNKJLeihpTrSb2Nf4JB37o6c4ozGs%3D&reserved=0
Also, if you want to see the tests for Vector, you can see them 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&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=GbM8oh6UkKpVE2HsdKwHgt6RgRJ9iNWIlCAhiubmHTk%3D&reserved=0
You should see large parts of that series of tests fail outside the
branch, and in some cases there were compiler errors too iirc (or maybe I
am confusing some compiler fixes I did for other things, can't be sure now)
On Sun, May 26, 2019 at 4:58 AM Carlos Rovira <ca...@apache.org>
wrote:
> Hi!
>
> Read it! :), was long but I think this emails are needed since it brings
> many thoughts that only the developer knows and otherwise would end never
> known by the rest of the community. So Great!
>
> Greg, first, many thanks for working on this. I think we get other point
> solved, and I think not only Vector, but many other fixes and things coming
> in your branch.
>
> For my part, as you said, the branch is tested against my real project,
> that I think is a very good way to test against lots of working code. So
> for my is ok to merge, not only cause it does not brake anything, but cause
> it's a big step forward.
>
> Since it brings things we didn't have before like Vector, is good to bring
> this. Then we can continue iterating to add missed things like AMF support
> or to evolve to other state or even change internal things if other check
> and see ways of enhancements.
>
> About the Vector implementation. My opinion is that I think as you that
> Vector is an intrinsic part of AS3, so better to have an implementation to
> complete AS3 in Royale. About having multiple implementations, I think that
> could be good in the future if things can be done that way, but better
> start from this starting point and see what happens in next months-years.
> IOW, better have a real implementation now that a potentially one that
> still is not here. We need to see the goal and approach to it progressively
> or we end getting nothing since the goal is a huge one not easy to reach.
>
> For me the 3kb is totally normal, and as well a great achievement of your
> implementation.
> I must say that my way of thinking in Royale is to be totally aligned with
> concepts like PAYG, but sometimes we need to break rules when the goal
> demand it, or we can end trying to apply the same principle to all things,
> when sometimes is not the best. So this is importante, rules are really
> good, but we need to always put behind a layer of human thinking about what
> we are trying to accomplish
>
> Thanks Greg for reaching another important milestone! Amazing work! :)
>
> Carlos
>
> PD: Piotr, about gmail cutting the email, I'm using gmail and get to read
> it completely, maybe could be a problem of gmail in mobile? I'm reading on
> gmail desktop. The only problem I had was reading posted source code, but
> since it was tiny, I could finally read it...
>
>
>
>
>
> El sáb., 25 may. 2019 a las 15:37, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
> > Hi Greg,
> >
> > Could you please post the code from this email in the paste.apache.org -
> > right now is unreadable in my Gmail account.
> >
> > Thanks,
> > Piotr
> >
> > On Sat, May 25, 2019, 4:51 AM Greg Dove <gr...@gmail.com> wrote:
> >
> > > OK, At the risk of making what follows even longer... a warning: *this
> > is a
> > > long read*. It might veer off topic in one or two places, but it is
> > mostly
> > > about why, and how Vector is implemented the way it is in the branch.
> > > Basically I would like to merge this branch into develop as soon as
> > > possible, i actually think it is ready as is, but I am keen to get
> other
> > > input before I do.
> > > Read it if you're interested. If you're not interested in reading it
> then
> > > please try the branch on any 'real' projects that you have in play.
> > Carlos
> > > has tested against his, and there are no issues, but it would be good
> to
> > > get wider input.
> > >
> > > now to the textual onslaught:
> > >
> > >
> > > *Vector*
> > >
> > > One of the things I did before I worked on this Vector implementation
> was
> > > to detach myself from ‘how I use Vector when I code’, to take a step
> back
> > > and challenge myself to rethink how I thought about it in general.
> > >
> > > Vector is *special*. Vector is not *a class* in a typical sense. It is
> > the
> > > closest thing that as3 has to generics which, when used at a class
> > level, I
> > > like to think of as the ability to generate multiple class variations
> > from
> > > a single class definition (that is just the way I think of them). So,
> at
> > > some level Vector could be considered as an infinite set of distinct
> > > classes, based on an infinite set of possible specified element types
> > > (whatever you see between the angle brackets in code). It is not
> actually
> > > implemented natively in AVM this way iiuc, but that is the outward
> > > appearance, and that is also the behaviour it has when using type
> > checking
> > > in as3.
> > >
> > > Aside from the runtime typesafe behaviour, Vector’s strong typing means
> > > there is additional compile time support and, related, the possibility
> of
> > > extra IDE support, both of which help the developer.
> > >
> > > Vector ‘types’ are also final ‘classes’ enforced by the compiler, so
> > cannot
> > > be extended.
> > >
> > > Additionally, on looking closer, there are some other quirky rules for
> > > runtime typing behaviour. These are related to the implementation in
> AVM.
> > > The 3 Vector types for Vector.<int>, Vector.<uint>, and Vector.<Number>
> > are
> > > individual base types, and then there is a 4th base type, Vector.<*>
> > which
> > > serves as the ‘base class’ of all other Vector ‘subclasses’. The 3
> > numeric
> > > types are faster than Array, and I expect this was the reason for the
> > > separation, because these are used in a lot of other flash apis,
> > > particularly for swapping with byte level data and things like
> BitmapData
> > > etc. The others are more simply for the strong typing aspects, because
> > > (perhaps less so with Boolean and String at a guess) they are somewhat
> > > slower than Array in AVM, because of the overhead of runtime
> typechecking
> > > and coercions etc. So the main selling points for choosing a Vector in
> > > flash were a) compile time and runtime type safety and b) faster
> > > performance for the 3 numeric Vector types.
> > >
> > > One implication of these ‘rules’ means that to check if *something* is
> a
> > > Vector of any type in swf, I need to do (mything is Vector.<int> ||
> > myThing
> > > is Vector.<uint> || myThing is Vector.<Number> || myThing is
> Vector.<*>)
> > or
> > > use reflection (which is slower).
> > >
> > > The above implies that, for language conformance (considered as
> > conformance
> > > with as3 documentation/spec and the behaviour of the reference
> > > implementation that we have for any ‘unknowns’) in an emulation, a
> > regular
> > > single as3 class implementation would not create a result that is
> > > consistent with the spec in terms of its representation of typing, and
> > its
> > > behaviour when using type checking.
> > >
> > > I tried to take all of these things into consideration.
> > >
> > >
> > >
> > > *How is it implemented in the branch?*
> > >
> > > Vector is implemented using the lightweight ‘synthType’ approach I
> added
> > > previously to support for int and uint types as ‘classes’. This
> provides
> > a
> > > light integration for ‘is’ and ‘as’ checks, but in javascript itself a
> > > Vector instance is simply a tagged native javascript Array instance
> (i.e.
> > > an Array with something that identifies it as being ‘not a regular
> > Array’).
> > > The Array methods are enhanced at the instance level to support the
> type
> > > coercions that take place in an actionscript Vector. Using Array makes
> > > sense because Vector instances are essentially typed Arrays. But it is
> > not
> > > possible to extend Array in javascript and have things work properly
> (it
> > is
> > > possible to use a different approach with es6 Proxy, but that is not
> > > available in IE11).
> > >
> > > This implementation also means that a ‘Vector’ instance should have
> > > functionality that works mostly as expected if it is passed directly to
> > a 3
> > > rd party native javascript library that is expecting an Array instance.
> > It
> > > will not support errors when changing the length if the Vector instance
> > is
> > > ‘fixed’ length, for example but otherwise it should function much the
> > same
> > > as a regular Array in the 3rd party code.
> > >
> > > The ‘synthType’ approach can be used because Vector types are final, so
> > it
> > > does not need to conform to a regular Royale class definition that can
> be
> > > extended and can be much ‘lighter’. As with int and uint ‘classes’, no
> > > Vector constructor exists until the first one is requested. There is
> one
> > > internal private class in Language that provides most of the
> > functionality
> > > for Vector, and element coercion functions are generated specifically
> for
> > > each Vector ‘subtype’. Overall, it behaves more like a subclass
> ‘factory’
> > > with each individual type’s constructor being created on demand and
> > cached
> > > for future use.
> > >
> > > Reflection and serialization support have not been added yet, but I
> > > certainly had these in mind also with this approach. I just wanted to
> > reach
> > > a sensible intermediate point for now, and then add those in later.
> > >
> > > In summary, the Vector implementation in the branch provides the
> > following:
> > >
> > > -distinct types (conforming in terms of type checking) for each Vector
> > > subtype
> > >
> > > -lightweight integration with Language ‘is’ and ‘as’ support
> > >
> > > -each Vector subtype has a unique constructor generated the first time
> it
> > > is requested, the constructor does not exist prior to that.
> > >
> > > -expected to be compatible with 3rd party native javascript that
> expects
> > a
> > > regular javascript Array
> > >
> > > -serialization (amf) and reflection are not yet supported but were
> > > considered, and that is planned as next steps.
> > >
> > > As at the time of writing, the current implementation is supported by
> 300
> > > Vector-specific assertions that run side-by-side between javascript and
> > swf
> > > in the manualtest UnitTests project. Apart from the differences created
> > by
> > > explicitly switching off some type safety checks with
> > > @suppressvectorindexchecking, there is only one verifiable difference
> in
> > > these tests between swf and javsacript. Probably there are things
> outside
> > > the test coverage that might need addressing still, but I think it’s a
> > > pretty good start.
> > >
> > > These tests should be easily ported to framework level unit tests
> > > (RoyaleUnit) as the same approach has been used to add FlexUnit tests
> in
> > > the past. Testing/Development is primarily in Chrome on windows, but
> the
> > > same tests were subsequently verified on IE11, Edge, Opera and Firefox
> on
> > > windows.
> > >
> > > *Implementation Info*
> > >
> > > *More quirks*
> > >
> > > A ‘fixed == true’ Vector cannot have its length changed. This means
> that
> > > changes via the length setter and the mutation methods (push, pop,
> shift,
> > > unshift etc) all throw errors if used when a Vector is ‘fixed == true’.
> > > But… splice method also can change length. And in AVM this works even
> > with
> > > a fixed length Vector, which might possibly be a bug but is one that is
> > > matched in the implementation to conform with flash.
> > >
> > > *Size impact.*
> > >
> > > Alex was concerned with size impact for HelloWorld because the beads
> were
> > > using a Vector.<IBead> type in javascript in one of the application
> > > framework base classes. But the requirement was for that to simply to
> be
> > an
> > > Array in javascript, the compiler was only achieving that by default
> > > because there was no real Vector implementation. So I did a couple of
> > > things here. Firstly I changed the application framework code to
> reflect
> > > the different requirement for javascript. Secondly, I added some doc
> > > comment directives to suppress exporting on public members. Then I
> added
> > > this to the Language methods that are for compiler-generated Vector
> (and
> > > int and uint) support so that they are eligible for dead code
> elimination
> > > if not used. This effectively means that it is fully PAYG – it is only
> > > there if you need it, but if you need it there is also no effort to add
> > it
> > > in as an optional dependency. If, because of this, there is a potential
> > for
> > > issues with modules or something I have not thought of, that will be
> > > another thing to solve, but if so, I will find a way to address it.
> > >
> > > If the main concern with ‘size’ is data transfer, then looking at the
> > > minified output size in HelloWorld is not really meaningful (or perhaps
> > it
> > > is better to say that it is only as meaningful as looking at the size
> of
> > an
> > > uncompressed swf compared to normal deployment of a compressed swf). In
> > any
> > > real deployment the javascript should be served as gzipped. So I
> compared
> > > gzipped (‘normal’ compression) versions of HelloWorld.js between those
> > with
> > > the unused Language support methods (for int/uint and Vector) and their
> > > dependencies vs. builds without. The support for all that functionality
> > > comes in at under 3 Kb difference in the gzipped output. I personally
> > don’t
> > > think that would register as important in most cases. However, it is
> > pretty
> > > close to zero impact now if it is not used. In fact the HelloWorld
> > > application is now about 55 bytes smaller than it was before, so I
> > consider
> > > it ‘carbon-netural’. And these are at the gzipped levels (it is also
> > > slightly smaller when not gzipped, although it can sometimes be the
> case
> > > that the larger of 2 files compresses better than a smaller one,
> > depending
> > > on the content).
> > >
> > > As a general comment about size… in my experience over the last 10
> years
> > or
> > > so, mostly in relation to Flex apps, size was most often not among the
> > > highest priority issues. Sure, start-up time often was. But that is not
> > > size per se. Often ‘size’ issues were first and foremost ‘asset size’
> > > issues (embedded or separate). While I know overall that it remains
> > > important, I personally think the growth in bandwidth and device memory
> > in
> > > general has outpaced the growth in the size of web apps even as the
> world
> > > has turned to mobile. In other words, I think we probably passed a
> hurdle
> > > point in the mobile side of things. Admittedly that is just
> ‘perception’
> > > and maybe there is data that shows I am quite wrong or your experience
> on
> > > specific client projects could be quite different. The point of me
> > > explaining that was, however, to illustrate why I think ‘size’ sits
> > where I
> > > think it does in general in terms of importance: I consider it to be
> > behind
> > > stability/reliability first which is followed by performance in
> > performance
> > > critical code. Overriding that general flow (which again, is just my
> > > opinion), are whatever my client’s specific requirements are for any
> > > particular project. In other words I am not sure how much of
> HelloWorld’s
> > > size is going to be an important deciding factor for someone to choose
> to
> > > use Royale. I think the ‘I got it to work!’ is the real kicker here.
> This
> > > paragraph was not to cause any conflict, and I already addressed the
> > ‘size’
> > > impact in the branch, so I’m not saying it wasn’t necessary to do that
> > > (although I do suspect the same attention was not given to all other
> > things
> > > in the past that affected HelloWorld). It’s more to promote discussion
> > and
> > > thought in general. Trying to be all one aspect (small size) can
> > compromise
> > > other aspects (reliability or stability or compatibility, for example).
> > And
> > > trying to accommodate all aspects (reliability, small size, exceptional
> > > performance) somehow very likely increases complexity because there is
> a
> > > need to accommodate the explicit decisions for trade-offs between
> > competing
> > > aspects. It would be good to have a guide of priorities based on the
> > needs
> > > of the user base (while I might have a strong opinion about what I
> think
> > is
> > > important, I don’t assume that my views necessarily represent wider
> user
> > > needs, because I have not done research to support that – and it’s not
> > > really a twitter poll kind of thing!). Anyhow I got off track there a
> > bit…
> > > back to Vector…
> > >
> > >
> > >
> > > *Performance.*
> > >
> > > No-one should expect a non-native Vector implementation to perform
> faster
> > > than native Array in javascript. Its main benefit is type safety, and
> > that
> > > is the reason it should be selected for use over Array. (In swf, native
> > > numeric Vector types *are* selected for performance, but the other
> Vector
> > > types are also at least slightly slower than Array, so selecting them
> is
> > > based on the need for type safety)
> > >
> > > There are, however some ways to get 100% Array performance with this
> > > implementation, and in a loop, for example it would be similar to
> > avoiding
> > > method calls (like push/pop) and only using index assignments that is
> > > typical of performance optimization in swf.
> > >
> > > So these two methods provide almost Identical performance in js:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > *private function testArrayInt2(iterations:uint):Number{ var
> > start:Date
> > > = new Date(); var inst:Array = new Array(iterations); for
> > (var
> > > i:uint=0;i<iterations; i++) { inst[i] = i; } return new
> > > Date().valueOf() - start.valueOf(); } /** * *
> > > @royalesuppressvectorindexcheck true */ private function
> > > testVectorInt2(iterations:uint):Number{ var start:Date = new
> Date();
> > > var inst:Vector.<uint> = new Vector.<uint>(iterations); for
> > > (var i:uint=0;i<iterations; i++) { inst[i] = i; }
> return
> > > new Date().valueOf() - start.valueOf(); }*
> > >
> > > The doc comment on the 2nd method prevented the compiler from
> generating
> > an
> > > index check wrapper around the ‘i’ in inst[i]
> > >
> > > The above 2 methods take around 5-7 ms for 500,000 iterations on my
> > machine
> > > (chrome/windows). This is quite a bit faster than the same methods in
> the
> > > swf (non-debug) build on my machine. The Vector constructor is also
> doing
> > > extra work in this case by setting all the 500,000 slots to numeric 0.
> > But
> > > on modern browsers it is using a fast native Array.fill method to do
> > that,
> > > so it’s probably more noticeable on IE11 which uses a for loop to
> > > pre-populate the contents with numeric 0 values.
> > >
> > > For reference, the generated code for the second method above, looks
> like
> > > this:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > */** * * @royalesuppressvectorindexcheck true * @private * @param
> > > {number} iterations * @return {number} */
> > >
> > >
> >
> flexUnitTests.language.LanguageTesterTestVectorPerf.prototype.flexUnitTests_language_LanguageTesterTestVectorPerf_testVectorInt2
> > > = function(iterations) { var /** @type {Date} */ start = new Date();
> > > var /** @type {Array.<number>} */ inst = new
> > > (org.apache.royale.utils.Language.synthVector('uint'))(iterations);
> for
> > > (var /** @type {number} */ i = 0; i < iterations; i++) { inst[i] =
> i;
> > > } return new Date().valueOf() - start.valueOf(); };*
> > >
> > > The methods with type checking in them, like push, unshift etc will be
> > > quite a lot slower though. This should not be a surprise. In swf, when
> > you
> > > look at something like Vector.<IBead> it can be up to 30% slower than
> > Array
> > > for methods like push, iirc at native level. In javascript it will be a
> > lot
> > > more. But in both cases it has type safety. And for small collection
> > sizes
> > > in non-performance sensitive code it is probably not going to make a
> > > meaningul difference.
> > >
> > > Known limitations
> > >
> > > 1. myVectorInstance[‘constructor’] can be different between js
> and
> > > swf
> > >
> > > 2. There is some reliance on not obscuring the type from the
> > compiler
> > > for things to work correctly. Example:
> > >
> > > var myObscuredType:* = new Vector.<String>(20,true) // creates a fixed
> > > Vector of length 20
> > >
> > > myObscuredType.length = 21; //should throw an error, but does not in
> > > javascript.
> > >
> > > This will work as long as the compiler knows that the type with the
> > length
> > > setter is some type of Vector, otherwise not.
> > >
> > >
> > >
> > > *Performance tuning*
> > >
> > > *@royalesuppressvectorindexcheck*
> > >
> > > The above doc comment directive avoids checking for out-of-valid-range
> > > index values on assignments. This is extremely desirable inside loops
> > which
> > > are usually constrained to the valid range in any case. There is a top
> > > level compiler configuration setting for this, but local settings win
> > > (turning off or on generally with true/false, or suppressing
> specifically
> > > for individual local variable names)
> > >
> > >
> > >
> > > Other options.
> > >
> > > The above one was obvious to me as an important tuning option. I
> started
> > > with adding another but pulled it out in favor of adding them based on
> > > actual need.
> > >
> > > There are many options:
> > >
> > > Instance based: reducing type checking with a compiler-only generated
> > > additional constructor parameter, triggered by some doc comment
> > directive.
> > > This could be in the form of adding in compiler generated alternatve
> > calls
> > > to things like ‘unsafePush’ and ‘unsafePop’ on instances, or perhaps
> > > literal calls to Array.prototype.push.call(inst, pushItem), triggered
> by
> > > some doc comment directive
> > >
> > > Global changes:Adding some compiler define value that (along with:
> > > ||goog.DEBUG) suppresses many runtime checks in the release Vector
> > > implementation. This would allow a blanket approach to dialing runtime
> > > safety down (or keeping them) in the release build. It would apply
> across
> > > all libraries and local project code.
> > >
> > > Some combinations of the above that allow sweeping optimizations with
> > local
> > > exceptions.
> > >
> > > Basically, this branch currently represents what I have reason to
> believe
> > > is a high conformance Vector implementation which should be the default
> > as
> > > it is an as3 core type. I think there are many options to scale things
> > > back, but rather than assume what they should be, I’d prefer to hear
> from
> > > users and address *real* needs, so that we only end up with
> configuration
> > > options that matter.
> > >
> > >
> > >
> > > *Advantages of a single Vector implementation – the case for avoiding a
> > > ‘vector emulation class’*
> > >
> > > ‘Language emulation’ is a foundational layer that is not in the same
> > > category as ‘application framework’ where we can define things how we
> > want.
> > > Because the royale sdk includes both aspects inside ‘framework’ (and
> that
> > > was obviously not the case for flex sdk in the past) it may be easy to
> > > overlook that difference.
> > >
> > > Vector typing is a core part of AS3 language. Therefore it should
> conform
> > > and be reliable. Having multiple implementations for a core language
> > > feature seems wrong and could easily lead to libraries of code that are
> > > incompatible. Additionally, as pointed out earlier, Vector is more
> like a
> > > subclass factory (‘runtime’ generics) than a single class, so won’t be
> > well
> > > represented by a regular class implementation.
> > >
> > > Alex, I know you added support for a Vector emulation class approach to
> > > meet the needs of someone asking for improved Vector support, in part
> > > because we did not have someone who had volunteered to write our own. I
> > did
> > > that last part now. I am also suggesting that the emulation class
> > approach
> > > is not a good long term solution because of the above reasons. And the
> > full
> > > set of functionality is less than 3Kb in the gzipped output, so I’d
> > suggest
> > > that as long as I can add needs-based performance tuning options for
> > those
> > > who want them, the benefits of having a single conforming
> implementation
> > > which is performance scalable are better than the risks associated with
> > > adding partially non-conforming ones. Therefore I’d like to ask if we
> can
> > > remove that functionality now that we have our own 'Vector' (I can do
> the
> > > work if you prefer as I know your focus is understandably on other
> > things).
> > >
> > > *Future:*
> > >
> > > It will be easily possibly to alter the current implementation to use
> es6
> > > proxy which would likely provide the most reliable way to get full
> Vector
> > > conformance indistinguishable from flash. Es6 proxy is transparent for
> > > Array:
> > >
> > > var p = new Proxy(new Array(), {});
> > >
> > > Array.isArray(p) // true
> > >
> > > This should allow trapping things like the length setter before it gets
> > to
> > > the underlying Array target, and doing checking for fixed == true etc.
> > The
> > > same is true for numeric index-based assignment of values etc.
> > >
> > > es6 Proxy is kinda cool. At the moment IE11 is the only meaningful
> target
> > > that does not support this.
> > >
> > > I am only mentioning this here because I did think about this, and I
> > > believe that the current implementation could be upgraded quite easily
> to
> > > use this approach if it makes sense (when IE11 is a distant memory –
> > > perhaps sometime next year!).
> > >
> > >
> > >
> > > Phew, you made it! Well done.
> > >
> > > Feel free to share your thoughts or ask any questions you might have.
> If
> > > you have neither of those at this time, please still try to find time
> to
> > > test any large projects you have in the branch, and provide feedback or
> > > share any concerns you might have after doing that.
> > > thanks,
> > > Greg
> > >
> > >
> > > On Thu, May 23, 2019 at 7:55 PM Greg Dove <gr...@gmail.com> wrote:
> > >
> > > > Re XMLTest manualtest...
> > > >
> > > > Yep those were the ones I ported, Harbs. I think I got them all but
> may
> > > > have missed some. I added a bunch more as well. Hopefully these can
> be
> > > > easily migrated to what Josh has been working on.
> > > >
> > > >
> > > > On Thu, 23 May 2019, 19:43 Harbs, <ha...@gmail.com> wrote:
> > > >
> > > >> As far as XML unit tests go, the starting point should be XMLTest in
> > > >> manual tests. (Almost) every time I ran into an issue, I added it to
> > > that
> > > >> project.
> > > >>
> > > >> I think I might have been lax on the last few issues I fixed, so we
> > > >> should probably go through the later XML commits and make sure we
> have
> > > >> tests for that.
> > > >>
> > > >> As far as Node goes, I think we probably need conditional Node
> > > >> compilation to handle Node-specific (and browser specific) code in a
> > > PAYG
> > > >> way.
> > > >>
> > > >> To technically handle the parsing, something like
> > > >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=5Rl9DZfo3zo%2Bk1q3x%2FygT4HehZ3IAkC5VGRHbKZ8Fbo%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fisaacs%2Fsax-js&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=5Rl9DZfo3zo%2Bk1q3x%2FygT4HehZ3IAkC5VGRHbKZ8Fbo%3D&reserved=0>
> > is
> > > a
> > > >> good starting point and something like this
> > > >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=TUTK%2BrNRsyS96dBdSDczi8qpEfTnhi4bgE5WmXORAnE%3D&reserved=0 <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfarina%2Fxmldoc&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=TUTK%2BrNRsyS96dBdSDczi8qpEfTnhi4bgE5WmXORAnE%3D&reserved=0>
> > > >> might be useful to either use or modify.
> > > >>
> > > >> Harbs
> > > >>
> > > >> > On May 23, 2019, at 10:18 AM, Greg Dove <gr...@gmail.com>
> > wrote:
> > > >> >
> > > >> > All, I started porting some adhoc XML tests to UnitTests and
> > > eventually
> > > >> > ended up spending quite a bit of time on addressing issues that
> > arose
> > > >> for
> > > >> > XML before getting back to Vector stuff.
> > > >> > I think XML probably needs many more unit tests before we get to
> 1.0
> > > >> > because it has an extensive api. I have not used royale with Node
> > yet,
> > > >> but
> > > >> > XML also needs some thought about how to get it working on Node, I
> > > >> assume.
> > > >> > Because XML uses the browser's parser and Node does not have one
> by
> > > >> > default, then using the same code will need something to take the
> > > place
> > > >> of
> > > >> > the browser's native parser for Node. There is a lib in npm that
> > might
> > > >> be
> > > >> > useful for that, but I don't know how that might work with licence
> > > etc.
> > > >> > Anyhow, that is just an observation, I will focus on Vector in
> this
> > > >> > thread... I will post here late tomorrow local time with more
> info,
> > > and
> > > >> > discussion points. I am keen to see this merged in, but also keen
> to
> > > get
> > > >> > buy-in first.
> > > >> >
> > > >> >
> > > >> > On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <
> > > carlosrovira@apache.org
> > > >> >
> > > >> > wrote:
> > > >> >
> > > >> >> 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.dove@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 <gr...@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
> > <aharui@adobe.com.invalid
> > > >
> > > >> >>>> wrote:
> > > >> >>>>
> > > >> >>>>> +1 to renaming the options to the positive.
> > > >> >>>>>
> > > >> >>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <jo...@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 <gr...@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%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=FgEQxhJYmuPRHJCp%2BU252ksKsI86IzXXC42N1V98sK8%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%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=0YKmOa48l7mIYYmuA6bJ%2FGQYDEd%2BMutJvSQp9k0sGyI%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%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=X8FK2azZSpsIHBZZCzfww4GAxxpOIeznBz7VOBr8WTg%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
> > > >> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=E6W9Pr%2FN8qCsgSOcyOyT9gnk5rq5fEtKQJW4Qb6UuxQ%3D&reserved=0
> > > >> >>
> > > >>
> > > >>
> > >
> >
>
>
> --
> Carlos Rovira
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cd686125447fc4a87d2ad08d6e15a45d9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636944175212072961&sdata=E6W9Pr%2FN8qCsgSOcyOyT9gnk5rq5fEtKQJW4Qb6UuxQ%3D&reserved=0
>
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
Hi Carlos, thanks for your feedback. In terms of PAYG, I just have a sense
that at the language level, the 'default' should be that it *works* as per
design.
If I take the example of Vector... then numeric Vector types will not run
faster in javascript. Using all the method calls will have a substantial
impact compared to using a normal Array. But code should 'work' the same
across targets.
I do have some ideas for application framework classes outside
'language'/Vector that would provide target-agnostic fast regular class
implementations for numeric typed Arrays, and I hope to work on that soon
as well, which takes more advantage of the optimized native options on each
target (Vector in swf, TypedArray in javascript). But to achieve that it
will likely be 'always fixed length' in this case, I will see if it seems
worth trying to be able to toggle that, or maybe it can be a bead or opt-in
support to get that functionality. But that should provide a good option
for developers seeking to get the best performance for numeric collections.
I expect to work on this during June.
Or developers can of course always choose to implement their own custom
performance code in COMPILE::JS / COMPILE::SWF variations, which is always
an option.
Hi Piotr, sorry about that email formatting issue. Thanks for your follow
up on this.
Here is a paste of that part, which includes the code.
https://paste.apache.org/dPWy
Also, if you want to see the tests for Vector, you can see them here:
https://github.com/apache/royale-asjs/blob/improvements/Language/manualtests/UnitTests/src/main/royale/flexUnitTests/language/LanguageTesterTestVector.as
You should see large parts of that series of tests fail outside the
branch, and in some cases there were compiler errors too iirc (or maybe I
am confusing some compiler fixes I did for other things, can't be sure now)
On Sun, May 26, 2019 at 4:58 AM Carlos Rovira <ca...@apache.org>
wrote:
> Hi!
>
> Read it! :), was long but I think this emails are needed since it brings
> many thoughts that only the developer knows and otherwise would end never
> known by the rest of the community. So Great!
>
> Greg, first, many thanks for working on this. I think we get other point
> solved, and I think not only Vector, but many other fixes and things coming
> in your branch.
>
> For my part, as you said, the branch is tested against my real project,
> that I think is a very good way to test against lots of working code. So
> for my is ok to merge, not only cause it does not brake anything, but cause
> it's a big step forward.
>
> Since it brings things we didn't have before like Vector, is good to bring
> this. Then we can continue iterating to add missed things like AMF support
> or to evolve to other state or even change internal things if other check
> and see ways of enhancements.
>
> About the Vector implementation. My opinion is that I think as you that
> Vector is an intrinsic part of AS3, so better to have an implementation to
> complete AS3 in Royale. About having multiple implementations, I think that
> could be good in the future if things can be done that way, but better
> start from this starting point and see what happens in next months-years.
> IOW, better have a real implementation now that a potentially one that
> still is not here. We need to see the goal and approach to it progressively
> or we end getting nothing since the goal is a huge one not easy to reach.
>
> For me the 3kb is totally normal, and as well a great achievement of your
> implementation.
> I must say that my way of thinking in Royale is to be totally aligned with
> concepts like PAYG, but sometimes we need to break rules when the goal
> demand it, or we can end trying to apply the same principle to all things,
> when sometimes is not the best. So this is importante, rules are really
> good, but we need to always put behind a layer of human thinking about what
> we are trying to accomplish
>
> Thanks Greg for reaching another important milestone! Amazing work! :)
>
> Carlos
>
> PD: Piotr, about gmail cutting the email, I'm using gmail and get to read
> it completely, maybe could be a problem of gmail in mobile? I'm reading on
> gmail desktop. The only problem I had was reading posted source code, but
> since it was tiny, I could finally read it...
>
>
>
>
>
> El sáb., 25 may. 2019 a las 15:37, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
> > Hi Greg,
> >
> > Could you please post the code from this email in the paste.apache.org -
> > right now is unreadable in my Gmail account.
> >
> > Thanks,
> > Piotr
> >
> > On Sat, May 25, 2019, 4:51 AM Greg Dove <gr...@gmail.com> wrote:
> >
> > > OK, At the risk of making what follows even longer... a warning: *this
> > is a
> > > long read*. It might veer off topic in one or two places, but it is
> > mostly
> > > about why, and how Vector is implemented the way it is in the branch.
> > > Basically I would like to merge this branch into develop as soon as
> > > possible, i actually think it is ready as is, but I am keen to get
> other
> > > input before I do.
> > > Read it if you're interested. If you're not interested in reading it
> then
> > > please try the branch on any 'real' projects that you have in play.
> > Carlos
> > > has tested against his, and there are no issues, but it would be good
> to
> > > get wider input.
> > >
> > > now to the textual onslaught:
> > >
> > >
> > > *Vector*
> > >
> > > One of the things I did before I worked on this Vector implementation
> was
> > > to detach myself from ‘how I use Vector when I code’, to take a step
> back
> > > and challenge myself to rethink how I thought about it in general.
> > >
> > > Vector is *special*. Vector is not *a class* in a typical sense. It is
> > the
> > > closest thing that as3 has to generics which, when used at a class
> > level, I
> > > like to think of as the ability to generate multiple class variations
> > from
> > > a single class definition (that is just the way I think of them). So,
> at
> > > some level Vector could be considered as an infinite set of distinct
> > > classes, based on an infinite set of possible specified element types
> > > (whatever you see between the angle brackets in code). It is not
> actually
> > > implemented natively in AVM this way iiuc, but that is the outward
> > > appearance, and that is also the behaviour it has when using type
> > checking
> > > in as3.
> > >
> > > Aside from the runtime typesafe behaviour, Vector’s strong typing means
> > > there is additional compile time support and, related, the possibility
> of
> > > extra IDE support, both of which help the developer.
> > >
> > > Vector ‘types’ are also final ‘classes’ enforced by the compiler, so
> > cannot
> > > be extended.
> > >
> > > Additionally, on looking closer, there are some other quirky rules for
> > > runtime typing behaviour. These are related to the implementation in
> AVM.
> > > The 3 Vector types for Vector.<int>, Vector.<uint>, and Vector.<Number>
> > are
> > > individual base types, and then there is a 4th base type, Vector.<*>
> > which
> > > serves as the ‘base class’ of all other Vector ‘subclasses’. The 3
> > numeric
> > > types are faster than Array, and I expect this was the reason for the
> > > separation, because these are used in a lot of other flash apis,
> > > particularly for swapping with byte level data and things like
> BitmapData
> > > etc. The others are more simply for the strong typing aspects, because
> > > (perhaps less so with Boolean and String at a guess) they are somewhat
> > > slower than Array in AVM, because of the overhead of runtime
> typechecking
> > > and coercions etc. So the main selling points for choosing a Vector in
> > > flash were a) compile time and runtime type safety and b) faster
> > > performance for the 3 numeric Vector types.
> > >
> > > One implication of these ‘rules’ means that to check if *something* is
> a
> > > Vector of any type in swf, I need to do (mything is Vector.<int> ||
> > myThing
> > > is Vector.<uint> || myThing is Vector.<Number> || myThing is
> Vector.<*>)
> > or
> > > use reflection (which is slower).
> > >
> > > The above implies that, for language conformance (considered as
> > conformance
> > > with as3 documentation/spec and the behaviour of the reference
> > > implementation that we have for any ‘unknowns’) in an emulation, a
> > regular
> > > single as3 class implementation would not create a result that is
> > > consistent with the spec in terms of its representation of typing, and
> > its
> > > behaviour when using type checking.
> > >
> > > I tried to take all of these things into consideration.
> > >
> > >
> > >
> > > *How is it implemented in the branch?*
> > >
> > > Vector is implemented using the lightweight ‘synthType’ approach I
> added
> > > previously to support for int and uint types as ‘classes’. This
> provides
> > a
> > > light integration for ‘is’ and ‘as’ checks, but in javascript itself a
> > > Vector instance is simply a tagged native javascript Array instance
> (i.e.
> > > an Array with something that identifies it as being ‘not a regular
> > Array’).
> > > The Array methods are enhanced at the instance level to support the
> type
> > > coercions that take place in an actionscript Vector. Using Array makes
> > > sense because Vector instances are essentially typed Arrays. But it is
> > not
> > > possible to extend Array in javascript and have things work properly
> (it
> > is
> > > possible to use a different approach with es6 Proxy, but that is not
> > > available in IE11).
> > >
> > > This implementation also means that a ‘Vector’ instance should have
> > > functionality that works mostly as expected if it is passed directly to
> > a 3
> > > rd party native javascript library that is expecting an Array instance.
> > It
> > > will not support errors when changing the length if the Vector instance
> > is
> > > ‘fixed’ length, for example but otherwise it should function much the
> > same
> > > as a regular Array in the 3rd party code.
> > >
> > > The ‘synthType’ approach can be used because Vector types are final, so
> > it
> > > does not need to conform to a regular Royale class definition that can
> be
> > > extended and can be much ‘lighter’. As with int and uint ‘classes’, no
> > > Vector constructor exists until the first one is requested. There is
> one
> > > internal private class in Language that provides most of the
> > functionality
> > > for Vector, and element coercion functions are generated specifically
> for
> > > each Vector ‘subtype’. Overall, it behaves more like a subclass
> ‘factory’
> > > with each individual type’s constructor being created on demand and
> > cached
> > > for future use.
> > >
> > > Reflection and serialization support have not been added yet, but I
> > > certainly had these in mind also with this approach. I just wanted to
> > reach
> > > a sensible intermediate point for now, and then add those in later.
> > >
> > > In summary, the Vector implementation in the branch provides the
> > following:
> > >
> > > -distinct types (conforming in terms of type checking) for each Vector
> > > subtype
> > >
> > > -lightweight integration with Language ‘is’ and ‘as’ support
> > >
> > > -each Vector subtype has a unique constructor generated the first time
> it
> > > is requested, the constructor does not exist prior to that.
> > >
> > > -expected to be compatible with 3rd party native javascript that
> expects
> > a
> > > regular javascript Array
> > >
> > > -serialization (amf) and reflection are not yet supported but were
> > > considered, and that is planned as next steps.
> > >
> > > As at the time of writing, the current implementation is supported by
> 300
> > > Vector-specific assertions that run side-by-side between javascript and
> > swf
> > > in the manualtest UnitTests project. Apart from the differences created
> > by
> > > explicitly switching off some type safety checks with
> > > @suppressvectorindexchecking, there is only one verifiable difference
> in
> > > these tests between swf and javsacript. Probably there are things
> outside
> > > the test coverage that might need addressing still, but I think it’s a
> > > pretty good start.
> > >
> > > These tests should be easily ported to framework level unit tests
> > > (RoyaleUnit) as the same approach has been used to add FlexUnit tests
> in
> > > the past. Testing/Development is primarily in Chrome on windows, but
> the
> > > same tests were subsequently verified on IE11, Edge, Opera and Firefox
> on
> > > windows.
> > >
> > > *Implementation Info*
> > >
> > > *More quirks*
> > >
> > > A ‘fixed == true’ Vector cannot have its length changed. This means
> that
> > > changes via the length setter and the mutation methods (push, pop,
> shift,
> > > unshift etc) all throw errors if used when a Vector is ‘fixed == true’.
> > > But… splice method also can change length. And in AVM this works even
> > with
> > > a fixed length Vector, which might possibly be a bug but is one that is
> > > matched in the implementation to conform with flash.
> > >
> > > *Size impact.*
> > >
> > > Alex was concerned with size impact for HelloWorld because the beads
> were
> > > using a Vector.<IBead> type in javascript in one of the application
> > > framework base classes. But the requirement was for that to simply to
> be
> > an
> > > Array in javascript, the compiler was only achieving that by default
> > > because there was no real Vector implementation. So I did a couple of
> > > things here. Firstly I changed the application framework code to
> reflect
> > > the different requirement for javascript. Secondly, I added some doc
> > > comment directives to suppress exporting on public members. Then I
> added
> > > this to the Language methods that are for compiler-generated Vector
> (and
> > > int and uint) support so that they are eligible for dead code
> elimination
> > > if not used. This effectively means that it is fully PAYG – it is only
> > > there if you need it, but if you need it there is also no effort to add
> > it
> > > in as an optional dependency. If, because of this, there is a potential
> > for
> > > issues with modules or something I have not thought of, that will be
> > > another thing to solve, but if so, I will find a way to address it.
> > >
> > > If the main concern with ‘size’ is data transfer, then looking at the
> > > minified output size in HelloWorld is not really meaningful (or perhaps
> > it
> > > is better to say that it is only as meaningful as looking at the size
> of
> > an
> > > uncompressed swf compared to normal deployment of a compressed swf). In
> > any
> > > real deployment the javascript should be served as gzipped. So I
> compared
> > > gzipped (‘normal’ compression) versions of HelloWorld.js between those
> > with
> > > the unused Language support methods (for int/uint and Vector) and their
> > > dependencies vs. builds without. The support for all that functionality
> > > comes in at under 3 Kb difference in the gzipped output. I personally
> > don’t
> > > think that would register as important in most cases. However, it is
> > pretty
> > > close to zero impact now if it is not used. In fact the HelloWorld
> > > application is now about 55 bytes smaller than it was before, so I
> > consider
> > > it ‘carbon-netural’. And these are at the gzipped levels (it is also
> > > slightly smaller when not gzipped, although it can sometimes be the
> case
> > > that the larger of 2 files compresses better than a smaller one,
> > depending
> > > on the content).
> > >
> > > As a general comment about size… in my experience over the last 10
> years
> > or
> > > so, mostly in relation to Flex apps, size was most often not among the
> > > highest priority issues. Sure, start-up time often was. But that is not
> > > size per se. Often ‘size’ issues were first and foremost ‘asset size’
> > > issues (embedded or separate). While I know overall that it remains
> > > important, I personally think the growth in bandwidth and device memory
> > in
> > > general has outpaced the growth in the size of web apps even as the
> world
> > > has turned to mobile. In other words, I think we probably passed a
> hurdle
> > > point in the mobile side of things. Admittedly that is just
> ‘perception’
> > > and maybe there is data that shows I am quite wrong or your experience
> on
> > > specific client projects could be quite different. The point of me
> > > explaining that was, however, to illustrate why I think ‘size’ sits
> > where I
> > > think it does in general in terms of importance: I consider it to be
> > behind
> > > stability/reliability first which is followed by performance in
> > performance
> > > critical code. Overriding that general flow (which again, is just my
> > > opinion), are whatever my client’s specific requirements are for any
> > > particular project. In other words I am not sure how much of
> HelloWorld’s
> > > size is going to be an important deciding factor for someone to choose
> to
> > > use Royale. I think the ‘I got it to work!’ is the real kicker here.
> This
> > > paragraph was not to cause any conflict, and I already addressed the
> > ‘size’
> > > impact in the branch, so I’m not saying it wasn’t necessary to do that
> > > (although I do suspect the same attention was not given to all other
> > things
> > > in the past that affected HelloWorld). It’s more to promote discussion
> > and
> > > thought in general. Trying to be all one aspect (small size) can
> > compromise
> > > other aspects (reliability or stability or compatibility, for example).
> > And
> > > trying to accommodate all aspects (reliability, small size, exceptional
> > > performance) somehow very likely increases complexity because there is
> a
> > > need to accommodate the explicit decisions for trade-offs between
> > competing
> > > aspects. It would be good to have a guide of priorities based on the
> > needs
> > > of the user base (while I might have a strong opinion about what I
> think
> > is
> > > important, I don’t assume that my views necessarily represent wider
> user
> > > needs, because I have not done research to support that – and it’s not
> > > really a twitter poll kind of thing!). Anyhow I got off track there a
> > bit…
> > > back to Vector…
> > >
> > >
> > >
> > > *Performance.*
> > >
> > > No-one should expect a non-native Vector implementation to perform
> faster
> > > than native Array in javascript. Its main benefit is type safety, and
> > that
> > > is the reason it should be selected for use over Array. (In swf, native
> > > numeric Vector types *are* selected for performance, but the other
> Vector
> > > types are also at least slightly slower than Array, so selecting them
> is
> > > based on the need for type safety)
> > >
> > > There are, however some ways to get 100% Array performance with this
> > > implementation, and in a loop, for example it would be similar to
> > avoiding
> > > method calls (like push/pop) and only using index assignments that is
> > > typical of performance optimization in swf.
> > >
> > > So these two methods provide almost Identical performance in js:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > *private function testArrayInt2(iterations:uint):Number{ var
> > start:Date
> > > = new Date(); var inst:Array = new Array(iterations); for
> > (var
> > > i:uint=0;i<iterations; i++) { inst[i] = i; } return new
> > > Date().valueOf() - start.valueOf(); } /** * *
> > > @royalesuppressvectorindexcheck true */ private function
> > > testVectorInt2(iterations:uint):Number{ var start:Date = new
> Date();
> > > var inst:Vector.<uint> = new Vector.<uint>(iterations); for
> > > (var i:uint=0;i<iterations; i++) { inst[i] = i; }
> return
> > > new Date().valueOf() - start.valueOf(); }*
> > >
> > > The doc comment on the 2nd method prevented the compiler from
> generating
> > an
> > > index check wrapper around the ‘i’ in inst[i]
> > >
> > > The above 2 methods take around 5-7 ms for 500,000 iterations on my
> > machine
> > > (chrome/windows). This is quite a bit faster than the same methods in
> the
> > > swf (non-debug) build on my machine. The Vector constructor is also
> doing
> > > extra work in this case by setting all the 500,000 slots to numeric 0.
> > But
> > > on modern browsers it is using a fast native Array.fill method to do
> > that,
> > > so it’s probably more noticeable on IE11 which uses a for loop to
> > > pre-populate the contents with numeric 0 values.
> > >
> > > For reference, the generated code for the second method above, looks
> like
> > > this:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > */** * * @royalesuppressvectorindexcheck true * @private * @param
> > > {number} iterations * @return {number} */
> > >
> > >
> >
> flexUnitTests.language.LanguageTesterTestVectorPerf.prototype.flexUnitTests_language_LanguageTesterTestVectorPerf_testVectorInt2
> > > = function(iterations) { var /** @type {Date} */ start = new Date();
> > > var /** @type {Array.<number>} */ inst = new
> > > (org.apache.royale.utils.Language.synthVector('uint'))(iterations);
> for
> > > (var /** @type {number} */ i = 0; i < iterations; i++) { inst[i] =
> i;
> > > } return new Date().valueOf() - start.valueOf(); };*
> > >
> > > The methods with type checking in them, like push, unshift etc will be
> > > quite a lot slower though. This should not be a surprise. In swf, when
> > you
> > > look at something like Vector.<IBead> it can be up to 30% slower than
> > Array
> > > for methods like push, iirc at native level. In javascript it will be a
> > lot
> > > more. But in both cases it has type safety. And for small collection
> > sizes
> > > in non-performance sensitive code it is probably not going to make a
> > > meaningul difference.
> > >
> > > Known limitations
> > >
> > > 1. myVectorInstance[‘constructor’] can be different between js
> and
> > > swf
> > >
> > > 2. There is some reliance on not obscuring the type from the
> > compiler
> > > for things to work correctly. Example:
> > >
> > > var myObscuredType:* = new Vector.<String>(20,true) // creates a fixed
> > > Vector of length 20
> > >
> > > myObscuredType.length = 21; //should throw an error, but does not in
> > > javascript.
> > >
> > > This will work as long as the compiler knows that the type with the
> > length
> > > setter is some type of Vector, otherwise not.
> > >
> > >
> > >
> > > *Performance tuning*
> > >
> > > *@royalesuppressvectorindexcheck*
> > >
> > > The above doc comment directive avoids checking for out-of-valid-range
> > > index values on assignments. This is extremely desirable inside loops
> > which
> > > are usually constrained to the valid range in any case. There is a top
> > > level compiler configuration setting for this, but local settings win
> > > (turning off or on generally with true/false, or suppressing
> specifically
> > > for individual local variable names)
> > >
> > >
> > >
> > > Other options.
> > >
> > > The above one was obvious to me as an important tuning option. I
> started
> > > with adding another but pulled it out in favor of adding them based on
> > > actual need.
> > >
> > > There are many options:
> > >
> > > Instance based: reducing type checking with a compiler-only generated
> > > additional constructor parameter, triggered by some doc comment
> > directive.
> > > This could be in the form of adding in compiler generated alternatve
> > calls
> > > to things like ‘unsafePush’ and ‘unsafePop’ on instances, or perhaps
> > > literal calls to Array.prototype.push.call(inst, pushItem), triggered
> by
> > > some doc comment directive
> > >
> > > Global changes:Adding some compiler define value that (along with:
> > > ||goog.DEBUG) suppresses many runtime checks in the release Vector
> > > implementation. This would allow a blanket approach to dialing runtime
> > > safety down (or keeping them) in the release build. It would apply
> across
> > > all libraries and local project code.
> > >
> > > Some combinations of the above that allow sweeping optimizations with
> > local
> > > exceptions.
> > >
> > > Basically, this branch currently represents what I have reason to
> believe
> > > is a high conformance Vector implementation which should be the default
> > as
> > > it is an as3 core type. I think there are many options to scale things
> > > back, but rather than assume what they should be, I’d prefer to hear
> from
> > > users and address *real* needs, so that we only end up with
> configuration
> > > options that matter.
> > >
> > >
> > >
> > > *Advantages of a single Vector implementation – the case for avoiding a
> > > ‘vector emulation class’*
> > >
> > > ‘Language emulation’ is a foundational layer that is not in the same
> > > category as ‘application framework’ where we can define things how we
> > want.
> > > Because the royale sdk includes both aspects inside ‘framework’ (and
> that
> > > was obviously not the case for flex sdk in the past) it may be easy to
> > > overlook that difference.
> > >
> > > Vector typing is a core part of AS3 language. Therefore it should
> conform
> > > and be reliable. Having multiple implementations for a core language
> > > feature seems wrong and could easily lead to libraries of code that are
> > > incompatible. Additionally, as pointed out earlier, Vector is more
> like a
> > > subclass factory (‘runtime’ generics) than a single class, so won’t be
> > well
> > > represented by a regular class implementation.
> > >
> > > Alex, I know you added support for a Vector emulation class approach to
> > > meet the needs of someone asking for improved Vector support, in part
> > > because we did not have someone who had volunteered to write our own. I
> > did
> > > that last part now. I am also suggesting that the emulation class
> > approach
> > > is not a good long term solution because of the above reasons. And the
> > full
> > > set of functionality is less than 3Kb in the gzipped output, so I’d
> > suggest
> > > that as long as I can add needs-based performance tuning options for
> > those
> > > who want them, the benefits of having a single conforming
> implementation
> > > which is performance scalable are better than the risks associated with
> > > adding partially non-conforming ones. Therefore I’d like to ask if we
> can
> > > remove that functionality now that we have our own 'Vector' (I can do
> the
> > > work if you prefer as I know your focus is understandably on other
> > things).
> > >
> > > *Future:*
> > >
> > > It will be easily possibly to alter the current implementation to use
> es6
> > > proxy which would likely provide the most reliable way to get full
> Vector
> > > conformance indistinguishable from flash. Es6 proxy is transparent for
> > > Array:
> > >
> > > var p = new Proxy(new Array(), {});
> > >
> > > Array.isArray(p) // true
> > >
> > > This should allow trapping things like the length setter before it gets
> > to
> > > the underlying Array target, and doing checking for fixed == true etc.
> > The
> > > same is true for numeric index-based assignment of values etc.
> > >
> > > es6 Proxy is kinda cool. At the moment IE11 is the only meaningful
> target
> > > that does not support this.
> > >
> > > I am only mentioning this here because I did think about this, and I
> > > believe that the current implementation could be upgraded quite easily
> to
> > > use this approach if it makes sense (when IE11 is a distant memory –
> > > perhaps sometime next year!).
> > >
> > >
> > >
> > > Phew, you made it! Well done.
> > >
> > > Feel free to share your thoughts or ask any questions you might have.
> If
> > > you have neither of those at this time, please still try to find time
> to
> > > test any large projects you have in the branch, and provide feedback or
> > > share any concerns you might have after doing that.
> > > thanks,
> > > Greg
> > >
> > >
> > > On Thu, May 23, 2019 at 7:55 PM Greg Dove <gr...@gmail.com> wrote:
> > >
> > > > Re XMLTest manualtest...
> > > >
> > > > Yep those were the ones I ported, Harbs. I think I got them all but
> may
> > > > have missed some. I added a bunch more as well. Hopefully these can
> be
> > > > easily migrated to what Josh has been working on.
> > > >
> > > >
> > > > On Thu, 23 May 2019, 19:43 Harbs, <ha...@gmail.com> wrote:
> > > >
> > > >> As far as XML unit tests go, the starting point should be XMLTest in
> > > >> manual tests. (Almost) every time I ran into an issue, I added it to
> > > that
> > > >> project.
> > > >>
> > > >> I think I might have been lax on the last few issues I fixed, so we
> > > >> should probably go through the later XML commits and make sure we
> have
> > > >> tests for that.
> > > >>
> > > >> As far as Node goes, I think we probably need conditional Node
> > > >> compilation to handle Node-specific (and browser specific) code in a
> > > PAYG
> > > >> way.
> > > >>
> > > >> To technically handle the parsing, something like
> > > >> https://github.com/isaacs/sax-js <https://github.com/isaacs/sax-js>
> > is
> > > a
> > > >> good starting point and something like this
> > > >> https://github.com/nfarina/xmldoc <
> https://github.com/nfarina/xmldoc>
> > > >> might be useful to either use or modify.
> > > >>
> > > >> Harbs
> > > >>
> > > >> > On May 23, 2019, at 10:18 AM, Greg Dove <gr...@gmail.com>
> > wrote:
> > > >> >
> > > >> > All, I started porting some adhoc XML tests to UnitTests and
> > > eventually
> > > >> > ended up spending quite a bit of time on addressing issues that
> > arose
> > > >> for
> > > >> > XML before getting back to Vector stuff.
> > > >> > I think XML probably needs many more unit tests before we get to
> 1.0
> > > >> > because it has an extensive api. I have not used royale with Node
> > yet,
> > > >> but
> > > >> > XML also needs some thought about how to get it working on Node, I
> > > >> assume.
> > > >> > Because XML uses the browser's parser and Node does not have one
> by
> > > >> > default, then using the same code will need something to take the
> > > place
> > > >> of
> > > >> > the browser's native parser for Node. There is a lib in npm that
> > might
> > > >> be
> > > >> > useful for that, but I don't know how that might work with licence
> > > etc.
> > > >> > Anyhow, that is just an observation, I will focus on Vector in
> this
> > > >> > thread... I will post here late tomorrow local time with more
> info,
> > > and
> > > >> > discussion points. I am keen to see this merged in, but also keen
> to
> > > get
> > > >> > buy-in first.
> > > >> >
> > > >> >
> > > >> > On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <
> > > carlosrovira@apache.org
> > > >> >
> > > >> > wrote:
> > > >> >
> > > >> >> 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.dove@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 <gr...@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
> > <aharui@adobe.com.invalid
> > > >
> > > >> >>>> wrote:
> > > >> >>>>
> > > >> >>>>> +1 to renaming the options to the positive.
> > > >> >>>>>
> > > >> >>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <jo...@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 <gr...@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
> > > >> >>
> > > >>
> > > >>
> > >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
Re: Language improvements
Posted by Carlos Rovira <ca...@apache.org>.
Hi!
Read it! :), was long but I think this emails are needed since it brings
many thoughts that only the developer knows and otherwise would end never
known by the rest of the community. So Great!
Greg, first, many thanks for working on this. I think we get other point
solved, and I think not only Vector, but many other fixes and things coming
in your branch.
For my part, as you said, the branch is tested against my real project,
that I think is a very good way to test against lots of working code. So
for my is ok to merge, not only cause it does not brake anything, but cause
it's a big step forward.
Since it brings things we didn't have before like Vector, is good to bring
this. Then we can continue iterating to add missed things like AMF support
or to evolve to other state or even change internal things if other check
and see ways of enhancements.
About the Vector implementation. My opinion is that I think as you that
Vector is an intrinsic part of AS3, so better to have an implementation to
complete AS3 in Royale. About having multiple implementations, I think that
could be good in the future if things can be done that way, but better
start from this starting point and see what happens in next months-years.
IOW, better have a real implementation now that a potentially one that
still is not here. We need to see the goal and approach to it progressively
or we end getting nothing since the goal is a huge one not easy to reach.
For me the 3kb is totally normal, and as well a great achievement of your
implementation.
I must say that my way of thinking in Royale is to be totally aligned with
concepts like PAYG, but sometimes we need to break rules when the goal
demand it, or we can end trying to apply the same principle to all things,
when sometimes is not the best. So this is importante, rules are really
good, but we need to always put behind a layer of human thinking about what
we are trying to accomplish
Thanks Greg for reaching another important milestone! Amazing work! :)
Carlos
PD: Piotr, about gmail cutting the email, I'm using gmail and get to read
it completely, maybe could be a problem of gmail in mobile? I'm reading on
gmail desktop. The only problem I had was reading posted source code, but
since it was tiny, I could finally read it...
El sáb., 25 may. 2019 a las 15:37, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:
> Hi Greg,
>
> Could you please post the code from this email in the paste.apache.org -
> right now is unreadable in my Gmail account.
>
> Thanks,
> Piotr
>
> On Sat, May 25, 2019, 4:51 AM Greg Dove <gr...@gmail.com> wrote:
>
> > OK, At the risk of making what follows even longer... a warning: *this
> is a
> > long read*. It might veer off topic in one or two places, but it is
> mostly
> > about why, and how Vector is implemented the way it is in the branch.
> > Basically I would like to merge this branch into develop as soon as
> > possible, i actually think it is ready as is, but I am keen to get other
> > input before I do.
> > Read it if you're interested. If you're not interested in reading it then
> > please try the branch on any 'real' projects that you have in play.
> Carlos
> > has tested against his, and there are no issues, but it would be good to
> > get wider input.
> >
> > now to the textual onslaught:
> >
> >
> > *Vector*
> >
> > One of the things I did before I worked on this Vector implementation was
> > to detach myself from ‘how I use Vector when I code’, to take a step back
> > and challenge myself to rethink how I thought about it in general.
> >
> > Vector is *special*. Vector is not *a class* in a typical sense. It is
> the
> > closest thing that as3 has to generics which, when used at a class
> level, I
> > like to think of as the ability to generate multiple class variations
> from
> > a single class definition (that is just the way I think of them). So, at
> > some level Vector could be considered as an infinite set of distinct
> > classes, based on an infinite set of possible specified element types
> > (whatever you see between the angle brackets in code). It is not actually
> > implemented natively in AVM this way iiuc, but that is the outward
> > appearance, and that is also the behaviour it has when using type
> checking
> > in as3.
> >
> > Aside from the runtime typesafe behaviour, Vector’s strong typing means
> > there is additional compile time support and, related, the possibility of
> > extra IDE support, both of which help the developer.
> >
> > Vector ‘types’ are also final ‘classes’ enforced by the compiler, so
> cannot
> > be extended.
> >
> > Additionally, on looking closer, there are some other quirky rules for
> > runtime typing behaviour. These are related to the implementation in AVM.
> > The 3 Vector types for Vector.<int>, Vector.<uint>, and Vector.<Number>
> are
> > individual base types, and then there is a 4th base type, Vector.<*>
> which
> > serves as the ‘base class’ of all other Vector ‘subclasses’. The 3
> numeric
> > types are faster than Array, and I expect this was the reason for the
> > separation, because these are used in a lot of other flash apis,
> > particularly for swapping with byte level data and things like BitmapData
> > etc. The others are more simply for the strong typing aspects, because
> > (perhaps less so with Boolean and String at a guess) they are somewhat
> > slower than Array in AVM, because of the overhead of runtime typechecking
> > and coercions etc. So the main selling points for choosing a Vector in
> > flash were a) compile time and runtime type safety and b) faster
> > performance for the 3 numeric Vector types.
> >
> > One implication of these ‘rules’ means that to check if *something* is a
> > Vector of any type in swf, I need to do (mything is Vector.<int> ||
> myThing
> > is Vector.<uint> || myThing is Vector.<Number> || myThing is Vector.<*>)
> or
> > use reflection (which is slower).
> >
> > The above implies that, for language conformance (considered as
> conformance
> > with as3 documentation/spec and the behaviour of the reference
> > implementation that we have for any ‘unknowns’) in an emulation, a
> regular
> > single as3 class implementation would not create a result that is
> > consistent with the spec in terms of its representation of typing, and
> its
> > behaviour when using type checking.
> >
> > I tried to take all of these things into consideration.
> >
> >
> >
> > *How is it implemented in the branch?*
> >
> > Vector is implemented using the lightweight ‘synthType’ approach I added
> > previously to support for int and uint types as ‘classes’. This provides
> a
> > light integration for ‘is’ and ‘as’ checks, but in javascript itself a
> > Vector instance is simply a tagged native javascript Array instance (i.e.
> > an Array with something that identifies it as being ‘not a regular
> Array’).
> > The Array methods are enhanced at the instance level to support the type
> > coercions that take place in an actionscript Vector. Using Array makes
> > sense because Vector instances are essentially typed Arrays. But it is
> not
> > possible to extend Array in javascript and have things work properly (it
> is
> > possible to use a different approach with es6 Proxy, but that is not
> > available in IE11).
> >
> > This implementation also means that a ‘Vector’ instance should have
> > functionality that works mostly as expected if it is passed directly to
> a 3
> > rd party native javascript library that is expecting an Array instance.
> It
> > will not support errors when changing the length if the Vector instance
> is
> > ‘fixed’ length, for example but otherwise it should function much the
> same
> > as a regular Array in the 3rd party code.
> >
> > The ‘synthType’ approach can be used because Vector types are final, so
> it
> > does not need to conform to a regular Royale class definition that can be
> > extended and can be much ‘lighter’. As with int and uint ‘classes’, no
> > Vector constructor exists until the first one is requested. There is one
> > internal private class in Language that provides most of the
> functionality
> > for Vector, and element coercion functions are generated specifically for
> > each Vector ‘subtype’. Overall, it behaves more like a subclass ‘factory’
> > with each individual type’s constructor being created on demand and
> cached
> > for future use.
> >
> > Reflection and serialization support have not been added yet, but I
> > certainly had these in mind also with this approach. I just wanted to
> reach
> > a sensible intermediate point for now, and then add those in later.
> >
> > In summary, the Vector implementation in the branch provides the
> following:
> >
> > -distinct types (conforming in terms of type checking) for each Vector
> > subtype
> >
> > -lightweight integration with Language ‘is’ and ‘as’ support
> >
> > -each Vector subtype has a unique constructor generated the first time it
> > is requested, the constructor does not exist prior to that.
> >
> > -expected to be compatible with 3rd party native javascript that expects
> a
> > regular javascript Array
> >
> > -serialization (amf) and reflection are not yet supported but were
> > considered, and that is planned as next steps.
> >
> > As at the time of writing, the current implementation is supported by 300
> > Vector-specific assertions that run side-by-side between javascript and
> swf
> > in the manualtest UnitTests project. Apart from the differences created
> by
> > explicitly switching off some type safety checks with
> > @suppressvectorindexchecking, there is only one verifiable difference in
> > these tests between swf and javsacript. Probably there are things outside
> > the test coverage that might need addressing still, but I think it’s a
> > pretty good start.
> >
> > These tests should be easily ported to framework level unit tests
> > (RoyaleUnit) as the same approach has been used to add FlexUnit tests in
> > the past. Testing/Development is primarily in Chrome on windows, but the
> > same tests were subsequently verified on IE11, Edge, Opera and Firefox on
> > windows.
> >
> > *Implementation Info*
> >
> > *More quirks*
> >
> > A ‘fixed == true’ Vector cannot have its length changed. This means that
> > changes via the length setter and the mutation methods (push, pop, shift,
> > unshift etc) all throw errors if used when a Vector is ‘fixed == true’.
> > But… splice method also can change length. And in AVM this works even
> with
> > a fixed length Vector, which might possibly be a bug but is one that is
> > matched in the implementation to conform with flash.
> >
> > *Size impact.*
> >
> > Alex was concerned with size impact for HelloWorld because the beads were
> > using a Vector.<IBead> type in javascript in one of the application
> > framework base classes. But the requirement was for that to simply to be
> an
> > Array in javascript, the compiler was only achieving that by default
> > because there was no real Vector implementation. So I did a couple of
> > things here. Firstly I changed the application framework code to reflect
> > the different requirement for javascript. Secondly, I added some doc
> > comment directives to suppress exporting on public members. Then I added
> > this to the Language methods that are for compiler-generated Vector (and
> > int and uint) support so that they are eligible for dead code elimination
> > if not used. This effectively means that it is fully PAYG – it is only
> > there if you need it, but if you need it there is also no effort to add
> it
> > in as an optional dependency. If, because of this, there is a potential
> for
> > issues with modules or something I have not thought of, that will be
> > another thing to solve, but if so, I will find a way to address it.
> >
> > If the main concern with ‘size’ is data transfer, then looking at the
> > minified output size in HelloWorld is not really meaningful (or perhaps
> it
> > is better to say that it is only as meaningful as looking at the size of
> an
> > uncompressed swf compared to normal deployment of a compressed swf). In
> any
> > real deployment the javascript should be served as gzipped. So I compared
> > gzipped (‘normal’ compression) versions of HelloWorld.js between those
> with
> > the unused Language support methods (for int/uint and Vector) and their
> > dependencies vs. builds without. The support for all that functionality
> > comes in at under 3 Kb difference in the gzipped output. I personally
> don’t
> > think that would register as important in most cases. However, it is
> pretty
> > close to zero impact now if it is not used. In fact the HelloWorld
> > application is now about 55 bytes smaller than it was before, so I
> consider
> > it ‘carbon-netural’. And these are at the gzipped levels (it is also
> > slightly smaller when not gzipped, although it can sometimes be the case
> > that the larger of 2 files compresses better than a smaller one,
> depending
> > on the content).
> >
> > As a general comment about size… in my experience over the last 10 years
> or
> > so, mostly in relation to Flex apps, size was most often not among the
> > highest priority issues. Sure, start-up time often was. But that is not
> > size per se. Often ‘size’ issues were first and foremost ‘asset size’
> > issues (embedded or separate). While I know overall that it remains
> > important, I personally think the growth in bandwidth and device memory
> in
> > general has outpaced the growth in the size of web apps even as the world
> > has turned to mobile. In other words, I think we probably passed a hurdle
> > point in the mobile side of things. Admittedly that is just ‘perception’
> > and maybe there is data that shows I am quite wrong or your experience on
> > specific client projects could be quite different. The point of me
> > explaining that was, however, to illustrate why I think ‘size’ sits
> where I
> > think it does in general in terms of importance: I consider it to be
> behind
> > stability/reliability first which is followed by performance in
> performance
> > critical code. Overriding that general flow (which again, is just my
> > opinion), are whatever my client’s specific requirements are for any
> > particular project. In other words I am not sure how much of HelloWorld’s
> > size is going to be an important deciding factor for someone to choose to
> > use Royale. I think the ‘I got it to work!’ is the real kicker here. This
> > paragraph was not to cause any conflict, and I already addressed the
> ‘size’
> > impact in the branch, so I’m not saying it wasn’t necessary to do that
> > (although I do suspect the same attention was not given to all other
> things
> > in the past that affected HelloWorld). It’s more to promote discussion
> and
> > thought in general. Trying to be all one aspect (small size) can
> compromise
> > other aspects (reliability or stability or compatibility, for example).
> And
> > trying to accommodate all aspects (reliability, small size, exceptional
> > performance) somehow very likely increases complexity because there is a
> > need to accommodate the explicit decisions for trade-offs between
> competing
> > aspects. It would be good to have a guide of priorities based on the
> needs
> > of the user base (while I might have a strong opinion about what I think
> is
> > important, I don’t assume that my views necessarily represent wider user
> > needs, because I have not done research to support that – and it’s not
> > really a twitter poll kind of thing!). Anyhow I got off track there a
> bit…
> > back to Vector…
> >
> >
> >
> > *Performance.*
> >
> > No-one should expect a non-native Vector implementation to perform faster
> > than native Array in javascript. Its main benefit is type safety, and
> that
> > is the reason it should be selected for use over Array. (In swf, native
> > numeric Vector types *are* selected for performance, but the other Vector
> > types are also at least slightly slower than Array, so selecting them is
> > based on the need for type safety)
> >
> > There are, however some ways to get 100% Array performance with this
> > implementation, and in a loop, for example it would be similar to
> avoiding
> > method calls (like push/pop) and only using index assignments that is
> > typical of performance optimization in swf.
> >
> > So these two methods provide almost Identical performance in js:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > *private function testArrayInt2(iterations:uint):Number{ var
> start:Date
> > = new Date(); var inst:Array = new Array(iterations); for
> (var
> > i:uint=0;i<iterations; i++) { inst[i] = i; } return new
> > Date().valueOf() - start.valueOf(); } /** * *
> > @royalesuppressvectorindexcheck true */ private function
> > testVectorInt2(iterations:uint):Number{ var start:Date = new Date();
> > var inst:Vector.<uint> = new Vector.<uint>(iterations); for
> > (var i:uint=0;i<iterations; i++) { inst[i] = i; } return
> > new Date().valueOf() - start.valueOf(); }*
> >
> > The doc comment on the 2nd method prevented the compiler from generating
> an
> > index check wrapper around the ‘i’ in inst[i]
> >
> > The above 2 methods take around 5-7 ms for 500,000 iterations on my
> machine
> > (chrome/windows). This is quite a bit faster than the same methods in the
> > swf (non-debug) build on my machine. The Vector constructor is also doing
> > extra work in this case by setting all the 500,000 slots to numeric 0.
> But
> > on modern browsers it is using a fast native Array.fill method to do
> that,
> > so it’s probably more noticeable on IE11 which uses a for loop to
> > pre-populate the contents with numeric 0 values.
> >
> > For reference, the generated code for the second method above, looks like
> > this:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > */** * * @royalesuppressvectorindexcheck true * @private * @param
> > {number} iterations * @return {number} */
> >
> >
> flexUnitTests.language.LanguageTesterTestVectorPerf.prototype.flexUnitTests_language_LanguageTesterTestVectorPerf_testVectorInt2
> > = function(iterations) { var /** @type {Date} */ start = new Date();
> > var /** @type {Array.<number>} */ inst = new
> > (org.apache.royale.utils.Language.synthVector('uint'))(iterations); for
> > (var /** @type {number} */ i = 0; i < iterations; i++) { inst[i] = i;
> > } return new Date().valueOf() - start.valueOf(); };*
> >
> > The methods with type checking in them, like push, unshift etc will be
> > quite a lot slower though. This should not be a surprise. In swf, when
> you
> > look at something like Vector.<IBead> it can be up to 30% slower than
> Array
> > for methods like push, iirc at native level. In javascript it will be a
> lot
> > more. But in both cases it has type safety. And for small collection
> sizes
> > in non-performance sensitive code it is probably not going to make a
> > meaningul difference.
> >
> > Known limitations
> >
> > 1. myVectorInstance[‘constructor’] can be different between js and
> > swf
> >
> > 2. There is some reliance on not obscuring the type from the
> compiler
> > for things to work correctly. Example:
> >
> > var myObscuredType:* = new Vector.<String>(20,true) // creates a fixed
> > Vector of length 20
> >
> > myObscuredType.length = 21; //should throw an error, but does not in
> > javascript.
> >
> > This will work as long as the compiler knows that the type with the
> length
> > setter is some type of Vector, otherwise not.
> >
> >
> >
> > *Performance tuning*
> >
> > *@royalesuppressvectorindexcheck*
> >
> > The above doc comment directive avoids checking for out-of-valid-range
> > index values on assignments. This is extremely desirable inside loops
> which
> > are usually constrained to the valid range in any case. There is a top
> > level compiler configuration setting for this, but local settings win
> > (turning off or on generally with true/false, or suppressing specifically
> > for individual local variable names)
> >
> >
> >
> > Other options.
> >
> > The above one was obvious to me as an important tuning option. I started
> > with adding another but pulled it out in favor of adding them based on
> > actual need.
> >
> > There are many options:
> >
> > Instance based: reducing type checking with a compiler-only generated
> > additional constructor parameter, triggered by some doc comment
> directive.
> > This could be in the form of adding in compiler generated alternatve
> calls
> > to things like ‘unsafePush’ and ‘unsafePop’ on instances, or perhaps
> > literal calls to Array.prototype.push.call(inst, pushItem), triggered by
> > some doc comment directive
> >
> > Global changes:Adding some compiler define value that (along with:
> > ||goog.DEBUG) suppresses many runtime checks in the release Vector
> > implementation. This would allow a blanket approach to dialing runtime
> > safety down (or keeping them) in the release build. It would apply across
> > all libraries and local project code.
> >
> > Some combinations of the above that allow sweeping optimizations with
> local
> > exceptions.
> >
> > Basically, this branch currently represents what I have reason to believe
> > is a high conformance Vector implementation which should be the default
> as
> > it is an as3 core type. I think there are many options to scale things
> > back, but rather than assume what they should be, I’d prefer to hear from
> > users and address *real* needs, so that we only end up with configuration
> > options that matter.
> >
> >
> >
> > *Advantages of a single Vector implementation – the case for avoiding a
> > ‘vector emulation class’*
> >
> > ‘Language emulation’ is a foundational layer that is not in the same
> > category as ‘application framework’ where we can define things how we
> want.
> > Because the royale sdk includes both aspects inside ‘framework’ (and that
> > was obviously not the case for flex sdk in the past) it may be easy to
> > overlook that difference.
> >
> > Vector typing is a core part of AS3 language. Therefore it should conform
> > and be reliable. Having multiple implementations for a core language
> > feature seems wrong and could easily lead to libraries of code that are
> > incompatible. Additionally, as pointed out earlier, Vector is more like a
> > subclass factory (‘runtime’ generics) than a single class, so won’t be
> well
> > represented by a regular class implementation.
> >
> > Alex, I know you added support for a Vector emulation class approach to
> > meet the needs of someone asking for improved Vector support, in part
> > because we did not have someone who had volunteered to write our own. I
> did
> > that last part now. I am also suggesting that the emulation class
> approach
> > is not a good long term solution because of the above reasons. And the
> full
> > set of functionality is less than 3Kb in the gzipped output, so I’d
> suggest
> > that as long as I can add needs-based performance tuning options for
> those
> > who want them, the benefits of having a single conforming implementation
> > which is performance scalable are better than the risks associated with
> > adding partially non-conforming ones. Therefore I’d like to ask if we can
> > remove that functionality now that we have our own 'Vector' (I can do the
> > work if you prefer as I know your focus is understandably on other
> things).
> >
> > *Future:*
> >
> > It will be easily possibly to alter the current implementation to use es6
> > proxy which would likely provide the most reliable way to get full Vector
> > conformance indistinguishable from flash. Es6 proxy is transparent for
> > Array:
> >
> > var p = new Proxy(new Array(), {});
> >
> > Array.isArray(p) // true
> >
> > This should allow trapping things like the length setter before it gets
> to
> > the underlying Array target, and doing checking for fixed == true etc.
> The
> > same is true for numeric index-based assignment of values etc.
> >
> > es6 Proxy is kinda cool. At the moment IE11 is the only meaningful target
> > that does not support this.
> >
> > I am only mentioning this here because I did think about this, and I
> > believe that the current implementation could be upgraded quite easily to
> > use this approach if it makes sense (when IE11 is a distant memory –
> > perhaps sometime next year!).
> >
> >
> >
> > Phew, you made it! Well done.
> >
> > Feel free to share your thoughts or ask any questions you might have. If
> > you have neither of those at this time, please still try to find time to
> > test any large projects you have in the branch, and provide feedback or
> > share any concerns you might have after doing that.
> > thanks,
> > Greg
> >
> >
> > On Thu, May 23, 2019 at 7:55 PM Greg Dove <gr...@gmail.com> wrote:
> >
> > > Re XMLTest manualtest...
> > >
> > > Yep those were the ones I ported, Harbs. I think I got them all but may
> > > have missed some. I added a bunch more as well. Hopefully these can be
> > > easily migrated to what Josh has been working on.
> > >
> > >
> > > On Thu, 23 May 2019, 19:43 Harbs, <ha...@gmail.com> wrote:
> > >
> > >> As far as XML unit tests go, the starting point should be XMLTest in
> > >> manual tests. (Almost) every time I ran into an issue, I added it to
> > that
> > >> project.
> > >>
> > >> I think I might have been lax on the last few issues I fixed, so we
> > >> should probably go through the later XML commits and make sure we have
> > >> tests for that.
> > >>
> > >> As far as Node goes, I think we probably need conditional Node
> > >> compilation to handle Node-specific (and browser specific) code in a
> > PAYG
> > >> way.
> > >>
> > >> To technically handle the parsing, something like
> > >> https://github.com/isaacs/sax-js <https://github.com/isaacs/sax-js>
> is
> > a
> > >> good starting point and something like this
> > >> https://github.com/nfarina/xmldoc <https://github.com/nfarina/xmldoc>
> > >> might be useful to either use or modify.
> > >>
> > >> Harbs
> > >>
> > >> > On May 23, 2019, at 10:18 AM, Greg Dove <gr...@gmail.com>
> wrote:
> > >> >
> > >> > All, I started porting some adhoc XML tests to UnitTests and
> > eventually
> > >> > ended up spending quite a bit of time on addressing issues that
> arose
> > >> for
> > >> > XML before getting back to Vector stuff.
> > >> > I think XML probably needs many more unit tests before we get to 1.0
> > >> > because it has an extensive api. I have not used royale with Node
> yet,
> > >> but
> > >> > XML also needs some thought about how to get it working on Node, I
> > >> assume.
> > >> > Because XML uses the browser's parser and Node does not have one by
> > >> > default, then using the same code will need something to take the
> > place
> > >> of
> > >> > the browser's native parser for Node. There is a lib in npm that
> might
> > >> be
> > >> > useful for that, but I don't know how that might work with licence
> > etc.
> > >> > Anyhow, that is just an observation, I will focus on Vector in this
> > >> > thread... I will post here late tomorrow local time with more info,
> > and
> > >> > discussion points. I am keen to see this merged in, but also keen to
> > get
> > >> > buy-in first.
> > >> >
> > >> >
> > >> > On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <
> > carlosrovira@apache.org
> > >> >
> > >> > wrote:
> > >> >
> > >> >> 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.dove@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 <gr...@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
> <aharui@adobe.com.invalid
> > >
> > >> >>>> wrote:
> > >> >>>>
> > >> >>>>> +1 to renaming the options to the positive.
> > >> >>>>>
> > >> >>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <jo...@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 <gr...@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
> > >> >>
> > >>
> > >>
> >
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Language improvements
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Greg,
Could you please post the code from this email in the paste.apache.org -
right now is unreadable in my Gmail account.
Thanks,
Piotr
On Sat, May 25, 2019, 4:51 AM Greg Dove <gr...@gmail.com> wrote:
> OK, At the risk of making what follows even longer... a warning: *this is a
> long read*. It might veer off topic in one or two places, but it is mostly
> about why, and how Vector is implemented the way it is in the branch.
> Basically I would like to merge this branch into develop as soon as
> possible, i actually think it is ready as is, but I am keen to get other
> input before I do.
> Read it if you're interested. If you're not interested in reading it then
> please try the branch on any 'real' projects that you have in play. Carlos
> has tested against his, and there are no issues, but it would be good to
> get wider input.
>
> now to the textual onslaught:
>
>
> *Vector*
>
> One of the things I did before I worked on this Vector implementation was
> to detach myself from ‘how I use Vector when I code’, to take a step back
> and challenge myself to rethink how I thought about it in general.
>
> Vector is *special*. Vector is not *a class* in a typical sense. It is the
> closest thing that as3 has to generics which, when used at a class level, I
> like to think of as the ability to generate multiple class variations from
> a single class definition (that is just the way I think of them). So, at
> some level Vector could be considered as an infinite set of distinct
> classes, based on an infinite set of possible specified element types
> (whatever you see between the angle brackets in code). It is not actually
> implemented natively in AVM this way iiuc, but that is the outward
> appearance, and that is also the behaviour it has when using type checking
> in as3.
>
> Aside from the runtime typesafe behaviour, Vector’s strong typing means
> there is additional compile time support and, related, the possibility of
> extra IDE support, both of which help the developer.
>
> Vector ‘types’ are also final ‘classes’ enforced by the compiler, so cannot
> be extended.
>
> Additionally, on looking closer, there are some other quirky rules for
> runtime typing behaviour. These are related to the implementation in AVM.
> The 3 Vector types for Vector.<int>, Vector.<uint>, and Vector.<Number> are
> individual base types, and then there is a 4th base type, Vector.<*> which
> serves as the ‘base class’ of all other Vector ‘subclasses’. The 3 numeric
> types are faster than Array, and I expect this was the reason for the
> separation, because these are used in a lot of other flash apis,
> particularly for swapping with byte level data and things like BitmapData
> etc. The others are more simply for the strong typing aspects, because
> (perhaps less so with Boolean and String at a guess) they are somewhat
> slower than Array in AVM, because of the overhead of runtime typechecking
> and coercions etc. So the main selling points for choosing a Vector in
> flash were a) compile time and runtime type safety and b) faster
> performance for the 3 numeric Vector types.
>
> One implication of these ‘rules’ means that to check if *something* is a
> Vector of any type in swf, I need to do (mything is Vector.<int> || myThing
> is Vector.<uint> || myThing is Vector.<Number> || myThing is Vector.<*>) or
> use reflection (which is slower).
>
> The above implies that, for language conformance (considered as conformance
> with as3 documentation/spec and the behaviour of the reference
> implementation that we have for any ‘unknowns’) in an emulation, a regular
> single as3 class implementation would not create a result that is
> consistent with the spec in terms of its representation of typing, and its
> behaviour when using type checking.
>
> I tried to take all of these things into consideration.
>
>
>
> *How is it implemented in the branch?*
>
> Vector is implemented using the lightweight ‘synthType’ approach I added
> previously to support for int and uint types as ‘classes’. This provides a
> light integration for ‘is’ and ‘as’ checks, but in javascript itself a
> Vector instance is simply a tagged native javascript Array instance (i.e.
> an Array with something that identifies it as being ‘not a regular Array’).
> The Array methods are enhanced at the instance level to support the type
> coercions that take place in an actionscript Vector. Using Array makes
> sense because Vector instances are essentially typed Arrays. But it is not
> possible to extend Array in javascript and have things work properly (it is
> possible to use a different approach with es6 Proxy, but that is not
> available in IE11).
>
> This implementation also means that a ‘Vector’ instance should have
> functionality that works mostly as expected if it is passed directly to a 3
> rd party native javascript library that is expecting an Array instance. It
> will not support errors when changing the length if the Vector instance is
> ‘fixed’ length, for example but otherwise it should function much the same
> as a regular Array in the 3rd party code.
>
> The ‘synthType’ approach can be used because Vector types are final, so it
> does not need to conform to a regular Royale class definition that can be
> extended and can be much ‘lighter’. As with int and uint ‘classes’, no
> Vector constructor exists until the first one is requested. There is one
> internal private class in Language that provides most of the functionality
> for Vector, and element coercion functions are generated specifically for
> each Vector ‘subtype’. Overall, it behaves more like a subclass ‘factory’
> with each individual type’s constructor being created on demand and cached
> for future use.
>
> Reflection and serialization support have not been added yet, but I
> certainly had these in mind also with this approach. I just wanted to reach
> a sensible intermediate point for now, and then add those in later.
>
> In summary, the Vector implementation in the branch provides the following:
>
> -distinct types (conforming in terms of type checking) for each Vector
> subtype
>
> -lightweight integration with Language ‘is’ and ‘as’ support
>
> -each Vector subtype has a unique constructor generated the first time it
> is requested, the constructor does not exist prior to that.
>
> -expected to be compatible with 3rd party native javascript that expects a
> regular javascript Array
>
> -serialization (amf) and reflection are not yet supported but were
> considered, and that is planned as next steps.
>
> As at the time of writing, the current implementation is supported by 300
> Vector-specific assertions that run side-by-side between javascript and swf
> in the manualtest UnitTests project. Apart from the differences created by
> explicitly switching off some type safety checks with
> @suppressvectorindexchecking, there is only one verifiable difference in
> these tests between swf and javsacript. Probably there are things outside
> the test coverage that might need addressing still, but I think it’s a
> pretty good start.
>
> These tests should be easily ported to framework level unit tests
> (RoyaleUnit) as the same approach has been used to add FlexUnit tests in
> the past. Testing/Development is primarily in Chrome on windows, but the
> same tests were subsequently verified on IE11, Edge, Opera and Firefox on
> windows.
>
> *Implementation Info*
>
> *More quirks*
>
> A ‘fixed == true’ Vector cannot have its length changed. This means that
> changes via the length setter and the mutation methods (push, pop, shift,
> unshift etc) all throw errors if used when a Vector is ‘fixed == true’.
> But… splice method also can change length. And in AVM this works even with
> a fixed length Vector, which might possibly be a bug but is one that is
> matched in the implementation to conform with flash.
>
> *Size impact.*
>
> Alex was concerned with size impact for HelloWorld because the beads were
> using a Vector.<IBead> type in javascript in one of the application
> framework base classes. But the requirement was for that to simply to be an
> Array in javascript, the compiler was only achieving that by default
> because there was no real Vector implementation. So I did a couple of
> things here. Firstly I changed the application framework code to reflect
> the different requirement for javascript. Secondly, I added some doc
> comment directives to suppress exporting on public members. Then I added
> this to the Language methods that are for compiler-generated Vector (and
> int and uint) support so that they are eligible for dead code elimination
> if not used. This effectively means that it is fully PAYG – it is only
> there if you need it, but if you need it there is also no effort to add it
> in as an optional dependency. If, because of this, there is a potential for
> issues with modules or something I have not thought of, that will be
> another thing to solve, but if so, I will find a way to address it.
>
> If the main concern with ‘size’ is data transfer, then looking at the
> minified output size in HelloWorld is not really meaningful (or perhaps it
> is better to say that it is only as meaningful as looking at the size of an
> uncompressed swf compared to normal deployment of a compressed swf). In any
> real deployment the javascript should be served as gzipped. So I compared
> gzipped (‘normal’ compression) versions of HelloWorld.js between those with
> the unused Language support methods (for int/uint and Vector) and their
> dependencies vs. builds without. The support for all that functionality
> comes in at under 3 Kb difference in the gzipped output. I personally don’t
> think that would register as important in most cases. However, it is pretty
> close to zero impact now if it is not used. In fact the HelloWorld
> application is now about 55 bytes smaller than it was before, so I consider
> it ‘carbon-netural’. And these are at the gzipped levels (it is also
> slightly smaller when not gzipped, although it can sometimes be the case
> that the larger of 2 files compresses better than a smaller one, depending
> on the content).
>
> As a general comment about size… in my experience over the last 10 years or
> so, mostly in relation to Flex apps, size was most often not among the
> highest priority issues. Sure, start-up time often was. But that is not
> size per se. Often ‘size’ issues were first and foremost ‘asset size’
> issues (embedded or separate). While I know overall that it remains
> important, I personally think the growth in bandwidth and device memory in
> general has outpaced the growth in the size of web apps even as the world
> has turned to mobile. In other words, I think we probably passed a hurdle
> point in the mobile side of things. Admittedly that is just ‘perception’
> and maybe there is data that shows I am quite wrong or your experience on
> specific client projects could be quite different. The point of me
> explaining that was, however, to illustrate why I think ‘size’ sits where I
> think it does in general in terms of importance: I consider it to be behind
> stability/reliability first which is followed by performance in performance
> critical code. Overriding that general flow (which again, is just my
> opinion), are whatever my client’s specific requirements are for any
> particular project. In other words I am not sure how much of HelloWorld’s
> size is going to be an important deciding factor for someone to choose to
> use Royale. I think the ‘I got it to work!’ is the real kicker here. This
> paragraph was not to cause any conflict, and I already addressed the ‘size’
> impact in the branch, so I’m not saying it wasn’t necessary to do that
> (although I do suspect the same attention was not given to all other things
> in the past that affected HelloWorld). It’s more to promote discussion and
> thought in general. Trying to be all one aspect (small size) can compromise
> other aspects (reliability or stability or compatibility, for example). And
> trying to accommodate all aspects (reliability, small size, exceptional
> performance) somehow very likely increases complexity because there is a
> need to accommodate the explicit decisions for trade-offs between competing
> aspects. It would be good to have a guide of priorities based on the needs
> of the user base (while I might have a strong opinion about what I think is
> important, I don’t assume that my views necessarily represent wider user
> needs, because I have not done research to support that – and it’s not
> really a twitter poll kind of thing!). Anyhow I got off track there a bit…
> back to Vector…
>
>
>
> *Performance.*
>
> No-one should expect a non-native Vector implementation to perform faster
> than native Array in javascript. Its main benefit is type safety, and that
> is the reason it should be selected for use over Array. (In swf, native
> numeric Vector types *are* selected for performance, but the other Vector
> types are also at least slightly slower than Array, so selecting them is
> based on the need for type safety)
>
> There are, however some ways to get 100% Array performance with this
> implementation, and in a loop, for example it would be similar to avoiding
> method calls (like push/pop) and only using index assignments that is
> typical of performance optimization in swf.
>
> So these two methods provide almost Identical performance in js:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *private function testArrayInt2(iterations:uint):Number{ var start:Date
> = new Date(); var inst:Array = new Array(iterations); for (var
> i:uint=0;i<iterations; i++) { inst[i] = i; } return new
> Date().valueOf() - start.valueOf(); } /** * *
> @royalesuppressvectorindexcheck true */ private function
> testVectorInt2(iterations:uint):Number{ var start:Date = new Date();
> var inst:Vector.<uint> = new Vector.<uint>(iterations); for
> (var i:uint=0;i<iterations; i++) { inst[i] = i; } return
> new Date().valueOf() - start.valueOf(); }*
>
> The doc comment on the 2nd method prevented the compiler from generating an
> index check wrapper around the ‘i’ in inst[i]
>
> The above 2 methods take around 5-7 ms for 500,000 iterations on my machine
> (chrome/windows). This is quite a bit faster than the same methods in the
> swf (non-debug) build on my machine. The Vector constructor is also doing
> extra work in this case by setting all the 500,000 slots to numeric 0. But
> on modern browsers it is using a fast native Array.fill method to do that,
> so it’s probably more noticeable on IE11 which uses a for loop to
> pre-populate the contents with numeric 0 values.
>
> For reference, the generated code for the second method above, looks like
> this:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> */** * * @royalesuppressvectorindexcheck true * @private * @param
> {number} iterations * @return {number} */
>
> flexUnitTests.language.LanguageTesterTestVectorPerf.prototype.flexUnitTests_language_LanguageTesterTestVectorPerf_testVectorInt2
> = function(iterations) { var /** @type {Date} */ start = new Date();
> var /** @type {Array.<number>} */ inst = new
> (org.apache.royale.utils.Language.synthVector('uint'))(iterations); for
> (var /** @type {number} */ i = 0; i < iterations; i++) { inst[i] = i;
> } return new Date().valueOf() - start.valueOf(); };*
>
> The methods with type checking in them, like push, unshift etc will be
> quite a lot slower though. This should not be a surprise. In swf, when you
> look at something like Vector.<IBead> it can be up to 30% slower than Array
> for methods like push, iirc at native level. In javascript it will be a lot
> more. But in both cases it has type safety. And for small collection sizes
> in non-performance sensitive code it is probably not going to make a
> meaningul difference.
>
> Known limitations
>
> 1. myVectorInstance[‘constructor’] can be different between js and
> swf
>
> 2. There is some reliance on not obscuring the type from the compiler
> for things to work correctly. Example:
>
> var myObscuredType:* = new Vector.<String>(20,true) // creates a fixed
> Vector of length 20
>
> myObscuredType.length = 21; //should throw an error, but does not in
> javascript.
>
> This will work as long as the compiler knows that the type with the length
> setter is some type of Vector, otherwise not.
>
>
>
> *Performance tuning*
>
> *@royalesuppressvectorindexcheck*
>
> The above doc comment directive avoids checking for out-of-valid-range
> index values on assignments. This is extremely desirable inside loops which
> are usually constrained to the valid range in any case. There is a top
> level compiler configuration setting for this, but local settings win
> (turning off or on generally with true/false, or suppressing specifically
> for individual local variable names)
>
>
>
> Other options.
>
> The above one was obvious to me as an important tuning option. I started
> with adding another but pulled it out in favor of adding them based on
> actual need.
>
> There are many options:
>
> Instance based: reducing type checking with a compiler-only generated
> additional constructor parameter, triggered by some doc comment directive.
> This could be in the form of adding in compiler generated alternatve calls
> to things like ‘unsafePush’ and ‘unsafePop’ on instances, or perhaps
> literal calls to Array.prototype.push.call(inst, pushItem), triggered by
> some doc comment directive
>
> Global changes:Adding some compiler define value that (along with:
> ||goog.DEBUG) suppresses many runtime checks in the release Vector
> implementation. This would allow a blanket approach to dialing runtime
> safety down (or keeping them) in the release build. It would apply across
> all libraries and local project code.
>
> Some combinations of the above that allow sweeping optimizations with local
> exceptions.
>
> Basically, this branch currently represents what I have reason to believe
> is a high conformance Vector implementation which should be the default as
> it is an as3 core type. I think there are many options to scale things
> back, but rather than assume what they should be, I’d prefer to hear from
> users and address *real* needs, so that we only end up with configuration
> options that matter.
>
>
>
> *Advantages of a single Vector implementation – the case for avoiding a
> ‘vector emulation class’*
>
> ‘Language emulation’ is a foundational layer that is not in the same
> category as ‘application framework’ where we can define things how we want.
> Because the royale sdk includes both aspects inside ‘framework’ (and that
> was obviously not the case for flex sdk in the past) it may be easy to
> overlook that difference.
>
> Vector typing is a core part of AS3 language. Therefore it should conform
> and be reliable. Having multiple implementations for a core language
> feature seems wrong and could easily lead to libraries of code that are
> incompatible. Additionally, as pointed out earlier, Vector is more like a
> subclass factory (‘runtime’ generics) than a single class, so won’t be well
> represented by a regular class implementation.
>
> Alex, I know you added support for a Vector emulation class approach to
> meet the needs of someone asking for improved Vector support, in part
> because we did not have someone who had volunteered to write our own. I did
> that last part now. I am also suggesting that the emulation class approach
> is not a good long term solution because of the above reasons. And the full
> set of functionality is less than 3Kb in the gzipped output, so I’d suggest
> that as long as I can add needs-based performance tuning options for those
> who want them, the benefits of having a single conforming implementation
> which is performance scalable are better than the risks associated with
> adding partially non-conforming ones. Therefore I’d like to ask if we can
> remove that functionality now that we have our own 'Vector' (I can do the
> work if you prefer as I know your focus is understandably on other things).
>
> *Future:*
>
> It will be easily possibly to alter the current implementation to use es6
> proxy which would likely provide the most reliable way to get full Vector
> conformance indistinguishable from flash. Es6 proxy is transparent for
> Array:
>
> var p = new Proxy(new Array(), {});
>
> Array.isArray(p) // true
>
> This should allow trapping things like the length setter before it gets to
> the underlying Array target, and doing checking for fixed == true etc. The
> same is true for numeric index-based assignment of values etc.
>
> es6 Proxy is kinda cool. At the moment IE11 is the only meaningful target
> that does not support this.
>
> I am only mentioning this here because I did think about this, and I
> believe that the current implementation could be upgraded quite easily to
> use this approach if it makes sense (when IE11 is a distant memory –
> perhaps sometime next year!).
>
>
>
> Phew, you made it! Well done.
>
> Feel free to share your thoughts or ask any questions you might have. If
> you have neither of those at this time, please still try to find time to
> test any large projects you have in the branch, and provide feedback or
> share any concerns you might have after doing that.
> thanks,
> Greg
>
>
> On Thu, May 23, 2019 at 7:55 PM Greg Dove <gr...@gmail.com> wrote:
>
> > Re XMLTest manualtest...
> >
> > Yep those were the ones I ported, Harbs. I think I got them all but may
> > have missed some. I added a bunch more as well. Hopefully these can be
> > easily migrated to what Josh has been working on.
> >
> >
> > On Thu, 23 May 2019, 19:43 Harbs, <ha...@gmail.com> wrote:
> >
> >> As far as XML unit tests go, the starting point should be XMLTest in
> >> manual tests. (Almost) every time I ran into an issue, I added it to
> that
> >> project.
> >>
> >> I think I might have been lax on the last few issues I fixed, so we
> >> should probably go through the later XML commits and make sure we have
> >> tests for that.
> >>
> >> As far as Node goes, I think we probably need conditional Node
> >> compilation to handle Node-specific (and browser specific) code in a
> PAYG
> >> way.
> >>
> >> To technically handle the parsing, something like
> >> https://github.com/isaacs/sax-js <https://github.com/isaacs/sax-js> is
> a
> >> good starting point and something like this
> >> https://github.com/nfarina/xmldoc <https://github.com/nfarina/xmldoc>
> >> might be useful to either use or modify.
> >>
> >> Harbs
> >>
> >> > On May 23, 2019, at 10:18 AM, Greg Dove <gr...@gmail.com> wrote:
> >> >
> >> > All, I started porting some adhoc XML tests to UnitTests and
> eventually
> >> > ended up spending quite a bit of time on addressing issues that arose
> >> for
> >> > XML before getting back to Vector stuff.
> >> > I think XML probably needs many more unit tests before we get to 1.0
> >> > because it has an extensive api. I have not used royale with Node yet,
> >> but
> >> > XML also needs some thought about how to get it working on Node, I
> >> assume.
> >> > Because XML uses the browser's parser and Node does not have one by
> >> > default, then using the same code will need something to take the
> place
> >> of
> >> > the browser's native parser for Node. There is a lib in npm that might
> >> be
> >> > useful for that, but I don't know how that might work with licence
> etc.
> >> > Anyhow, that is just an observation, I will focus on Vector in this
> >> > thread... I will post here late tomorrow local time with more info,
> and
> >> > discussion points. I am keen to see this merged in, but also keen to
> get
> >> > buy-in first.
> >> >
> >> >
> >> > On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <
> carlosrovira@apache.org
> >> >
> >> > wrote:
> >> >
> >> >> 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 (<gr...@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 <gr...@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 <aharui@adobe.com.invalid
> >
> >> >>>> wrote:
> >> >>>>
> >> >>>>> +1 to renaming the options to the positive.
> >> >>>>>
> >> >>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <jo...@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 <gr...@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
> >> >>
> >>
> >>
>
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
OK, At the risk of making what follows even longer... a warning: *this is a
long read*. It might veer off topic in one or two places, but it is mostly
about why, and how Vector is implemented the way it is in the branch.
Basically I would like to merge this branch into develop as soon as
possible, i actually think it is ready as is, but I am keen to get other
input before I do.
Read it if you're interested. If you're not interested in reading it then
please try the branch on any 'real' projects that you have in play. Carlos
has tested against his, and there are no issues, but it would be good to
get wider input.
now to the textual onslaught:
*Vector*
One of the things I did before I worked on this Vector implementation was
to detach myself from ‘how I use Vector when I code’, to take a step back
and challenge myself to rethink how I thought about it in general.
Vector is *special*. Vector is not *a class* in a typical sense. It is the
closest thing that as3 has to generics which, when used at a class level, I
like to think of as the ability to generate multiple class variations from
a single class definition (that is just the way I think of them). So, at
some level Vector could be considered as an infinite set of distinct
classes, based on an infinite set of possible specified element types
(whatever you see between the angle brackets in code). It is not actually
implemented natively in AVM this way iiuc, but that is the outward
appearance, and that is also the behaviour it has when using type checking
in as3.
Aside from the runtime typesafe behaviour, Vector’s strong typing means
there is additional compile time support and, related, the possibility of
extra IDE support, both of which help the developer.
Vector ‘types’ are also final ‘classes’ enforced by the compiler, so cannot
be extended.
Additionally, on looking closer, there are some other quirky rules for
runtime typing behaviour. These are related to the implementation in AVM.
The 3 Vector types for Vector.<int>, Vector.<uint>, and Vector.<Number> are
individual base types, and then there is a 4th base type, Vector.<*> which
serves as the ‘base class’ of all other Vector ‘subclasses’. The 3 numeric
types are faster than Array, and I expect this was the reason for the
separation, because these are used in a lot of other flash apis,
particularly for swapping with byte level data and things like BitmapData
etc. The others are more simply for the strong typing aspects, because
(perhaps less so with Boolean and String at a guess) they are somewhat
slower than Array in AVM, because of the overhead of runtime typechecking
and coercions etc. So the main selling points for choosing a Vector in
flash were a) compile time and runtime type safety and b) faster
performance for the 3 numeric Vector types.
One implication of these ‘rules’ means that to check if *something* is a
Vector of any type in swf, I need to do (mything is Vector.<int> || myThing
is Vector.<uint> || myThing is Vector.<Number> || myThing is Vector.<*>) or
use reflection (which is slower).
The above implies that, for language conformance (considered as conformance
with as3 documentation/spec and the behaviour of the reference
implementation that we have for any ‘unknowns’) in an emulation, a regular
single as3 class implementation would not create a result that is
consistent with the spec in terms of its representation of typing, and its
behaviour when using type checking.
I tried to take all of these things into consideration.
*How is it implemented in the branch?*
Vector is implemented using the lightweight ‘synthType’ approach I added
previously to support for int and uint types as ‘classes’. This provides a
light integration for ‘is’ and ‘as’ checks, but in javascript itself a
Vector instance is simply a tagged native javascript Array instance (i.e.
an Array with something that identifies it as being ‘not a regular Array’).
The Array methods are enhanced at the instance level to support the type
coercions that take place in an actionscript Vector. Using Array makes
sense because Vector instances are essentially typed Arrays. But it is not
possible to extend Array in javascript and have things work properly (it is
possible to use a different approach with es6 Proxy, but that is not
available in IE11).
This implementation also means that a ‘Vector’ instance should have
functionality that works mostly as expected if it is passed directly to a 3
rd party native javascript library that is expecting an Array instance. It
will not support errors when changing the length if the Vector instance is
‘fixed’ length, for example but otherwise it should function much the same
as a regular Array in the 3rd party code.
The ‘synthType’ approach can be used because Vector types are final, so it
does not need to conform to a regular Royale class definition that can be
extended and can be much ‘lighter’. As with int and uint ‘classes’, no
Vector constructor exists until the first one is requested. There is one
internal private class in Language that provides most of the functionality
for Vector, and element coercion functions are generated specifically for
each Vector ‘subtype’. Overall, it behaves more like a subclass ‘factory’
with each individual type’s constructor being created on demand and cached
for future use.
Reflection and serialization support have not been added yet, but I
certainly had these in mind also with this approach. I just wanted to reach
a sensible intermediate point for now, and then add those in later.
In summary, the Vector implementation in the branch provides the following:
-distinct types (conforming in terms of type checking) for each Vector
subtype
-lightweight integration with Language ‘is’ and ‘as’ support
-each Vector subtype has a unique constructor generated the first time it
is requested, the constructor does not exist prior to that.
-expected to be compatible with 3rd party native javascript that expects a
regular javascript Array
-serialization (amf) and reflection are not yet supported but were
considered, and that is planned as next steps.
As at the time of writing, the current implementation is supported by 300
Vector-specific assertions that run side-by-side between javascript and swf
in the manualtest UnitTests project. Apart from the differences created by
explicitly switching off some type safety checks with
@suppressvectorindexchecking, there is only one verifiable difference in
these tests between swf and javsacript. Probably there are things outside
the test coverage that might need addressing still, but I think it’s a
pretty good start.
These tests should be easily ported to framework level unit tests
(RoyaleUnit) as the same approach has been used to add FlexUnit tests in
the past. Testing/Development is primarily in Chrome on windows, but the
same tests were subsequently verified on IE11, Edge, Opera and Firefox on
windows.
*Implementation Info*
*More quirks*
A ‘fixed == true’ Vector cannot have its length changed. This means that
changes via the length setter and the mutation methods (push, pop, shift,
unshift etc) all throw errors if used when a Vector is ‘fixed == true’.
But… splice method also can change length. And in AVM this works even with
a fixed length Vector, which might possibly be a bug but is one that is
matched in the implementation to conform with flash.
*Size impact.*
Alex was concerned with size impact for HelloWorld because the beads were
using a Vector.<IBead> type in javascript in one of the application
framework base classes. But the requirement was for that to simply to be an
Array in javascript, the compiler was only achieving that by default
because there was no real Vector implementation. So I did a couple of
things here. Firstly I changed the application framework code to reflect
the different requirement for javascript. Secondly, I added some doc
comment directives to suppress exporting on public members. Then I added
this to the Language methods that are for compiler-generated Vector (and
int and uint) support so that they are eligible for dead code elimination
if not used. This effectively means that it is fully PAYG – it is only
there if you need it, but if you need it there is also no effort to add it
in as an optional dependency. If, because of this, there is a potential for
issues with modules or something I have not thought of, that will be
another thing to solve, but if so, I will find a way to address it.
If the main concern with ‘size’ is data transfer, then looking at the
minified output size in HelloWorld is not really meaningful (or perhaps it
is better to say that it is only as meaningful as looking at the size of an
uncompressed swf compared to normal deployment of a compressed swf). In any
real deployment the javascript should be served as gzipped. So I compared
gzipped (‘normal’ compression) versions of HelloWorld.js between those with
the unused Language support methods (for int/uint and Vector) and their
dependencies vs. builds without. The support for all that functionality
comes in at under 3 Kb difference in the gzipped output. I personally don’t
think that would register as important in most cases. However, it is pretty
close to zero impact now if it is not used. In fact the HelloWorld
application is now about 55 bytes smaller than it was before, so I consider
it ‘carbon-netural’. And these are at the gzipped levels (it is also
slightly smaller when not gzipped, although it can sometimes be the case
that the larger of 2 files compresses better than a smaller one, depending
on the content).
As a general comment about size… in my experience over the last 10 years or
so, mostly in relation to Flex apps, size was most often not among the
highest priority issues. Sure, start-up time often was. But that is not
size per se. Often ‘size’ issues were first and foremost ‘asset size’
issues (embedded or separate). While I know overall that it remains
important, I personally think the growth in bandwidth and device memory in
general has outpaced the growth in the size of web apps even as the world
has turned to mobile. In other words, I think we probably passed a hurdle
point in the mobile side of things. Admittedly that is just ‘perception’
and maybe there is data that shows I am quite wrong or your experience on
specific client projects could be quite different. The point of me
explaining that was, however, to illustrate why I think ‘size’ sits where I
think it does in general in terms of importance: I consider it to be behind
stability/reliability first which is followed by performance in performance
critical code. Overriding that general flow (which again, is just my
opinion), are whatever my client’s specific requirements are for any
particular project. In other words I am not sure how much of HelloWorld’s
size is going to be an important deciding factor for someone to choose to
use Royale. I think the ‘I got it to work!’ is the real kicker here. This
paragraph was not to cause any conflict, and I already addressed the ‘size’
impact in the branch, so I’m not saying it wasn’t necessary to do that
(although I do suspect the same attention was not given to all other things
in the past that affected HelloWorld). It’s more to promote discussion and
thought in general. Trying to be all one aspect (small size) can compromise
other aspects (reliability or stability or compatibility, for example). And
trying to accommodate all aspects (reliability, small size, exceptional
performance) somehow very likely increases complexity because there is a
need to accommodate the explicit decisions for trade-offs between competing
aspects. It would be good to have a guide of priorities based on the needs
of the user base (while I might have a strong opinion about what I think is
important, I don’t assume that my views necessarily represent wider user
needs, because I have not done research to support that – and it’s not
really a twitter poll kind of thing!). Anyhow I got off track there a bit…
back to Vector…
*Performance.*
No-one should expect a non-native Vector implementation to perform faster
than native Array in javascript. Its main benefit is type safety, and that
is the reason it should be selected for use over Array. (In swf, native
numeric Vector types *are* selected for performance, but the other Vector
types are also at least slightly slower than Array, so selecting them is
based on the need for type safety)
There are, however some ways to get 100% Array performance with this
implementation, and in a loop, for example it would be similar to avoiding
method calls (like push/pop) and only using index assignments that is
typical of performance optimization in swf.
So these two methods provide almost Identical performance in js:
*private function testArrayInt2(iterations:uint):Number{ var start:Date
= new Date(); var inst:Array = new Array(iterations); for (var
i:uint=0;i<iterations; i++) { inst[i] = i; } return new
Date().valueOf() - start.valueOf(); } /** * *
@royalesuppressvectorindexcheck true */ private function
testVectorInt2(iterations:uint):Number{ var start:Date = new Date();
var inst:Vector.<uint> = new Vector.<uint>(iterations); for
(var i:uint=0;i<iterations; i++) { inst[i] = i; } return
new Date().valueOf() - start.valueOf(); }*
The doc comment on the 2nd method prevented the compiler from generating an
index check wrapper around the ‘i’ in inst[i]
The above 2 methods take around 5-7 ms for 500,000 iterations on my machine
(chrome/windows). This is quite a bit faster than the same methods in the
swf (non-debug) build on my machine. The Vector constructor is also doing
extra work in this case by setting all the 500,000 slots to numeric 0. But
on modern browsers it is using a fast native Array.fill method to do that,
so it’s probably more noticeable on IE11 which uses a for loop to
pre-populate the contents with numeric 0 values.
For reference, the generated code for the second method above, looks like
this:
*/** * * @royalesuppressvectorindexcheck true * @private * @param
{number} iterations * @return {number} */
flexUnitTests.language.LanguageTesterTestVectorPerf.prototype.flexUnitTests_language_LanguageTesterTestVectorPerf_testVectorInt2
= function(iterations) { var /** @type {Date} */ start = new Date();
var /** @type {Array.<number>} */ inst = new
(org.apache.royale.utils.Language.synthVector('uint'))(iterations); for
(var /** @type {number} */ i = 0; i < iterations; i++) { inst[i] = i;
} return new Date().valueOf() - start.valueOf(); };*
The methods with type checking in them, like push, unshift etc will be
quite a lot slower though. This should not be a surprise. In swf, when you
look at something like Vector.<IBead> it can be up to 30% slower than Array
for methods like push, iirc at native level. In javascript it will be a lot
more. But in both cases it has type safety. And for small collection sizes
in non-performance sensitive code it is probably not going to make a
meaningul difference.
Known limitations
1. myVectorInstance[‘constructor’] can be different between js and swf
2. There is some reliance on not obscuring the type from the compiler
for things to work correctly. Example:
var myObscuredType:* = new Vector.<String>(20,true) // creates a fixed
Vector of length 20
myObscuredType.length = 21; //should throw an error, but does not in
javascript.
This will work as long as the compiler knows that the type with the length
setter is some type of Vector, otherwise not.
*Performance tuning*
*@royalesuppressvectorindexcheck*
The above doc comment directive avoids checking for out-of-valid-range
index values on assignments. This is extremely desirable inside loops which
are usually constrained to the valid range in any case. There is a top
level compiler configuration setting for this, but local settings win
(turning off or on generally with true/false, or suppressing specifically
for individual local variable names)
Other options.
The above one was obvious to me as an important tuning option. I started
with adding another but pulled it out in favor of adding them based on
actual need.
There are many options:
Instance based: reducing type checking with a compiler-only generated
additional constructor parameter, triggered by some doc comment directive.
This could be in the form of adding in compiler generated alternatve calls
to things like ‘unsafePush’ and ‘unsafePop’ on instances, or perhaps
literal calls to Array.prototype.push.call(inst, pushItem), triggered by
some doc comment directive
Global changes:Adding some compiler define value that (along with:
||goog.DEBUG) suppresses many runtime checks in the release Vector
implementation. This would allow a blanket approach to dialing runtime
safety down (or keeping them) in the release build. It would apply across
all libraries and local project code.
Some combinations of the above that allow sweeping optimizations with local
exceptions.
Basically, this branch currently represents what I have reason to believe
is a high conformance Vector implementation which should be the default as
it is an as3 core type. I think there are many options to scale things
back, but rather than assume what they should be, I’d prefer to hear from
users and address *real* needs, so that we only end up with configuration
options that matter.
*Advantages of a single Vector implementation – the case for avoiding a
‘vector emulation class’*
‘Language emulation’ is a foundational layer that is not in the same
category as ‘application framework’ where we can define things how we want.
Because the royale sdk includes both aspects inside ‘framework’ (and that
was obviously not the case for flex sdk in the past) it may be easy to
overlook that difference.
Vector typing is a core part of AS3 language. Therefore it should conform
and be reliable. Having multiple implementations for a core language
feature seems wrong and could easily lead to libraries of code that are
incompatible. Additionally, as pointed out earlier, Vector is more like a
subclass factory (‘runtime’ generics) than a single class, so won’t be well
represented by a regular class implementation.
Alex, I know you added support for a Vector emulation class approach to
meet the needs of someone asking for improved Vector support, in part
because we did not have someone who had volunteered to write our own. I did
that last part now. I am also suggesting that the emulation class approach
is not a good long term solution because of the above reasons. And the full
set of functionality is less than 3Kb in the gzipped output, so I’d suggest
that as long as I can add needs-based performance tuning options for those
who want them, the benefits of having a single conforming implementation
which is performance scalable are better than the risks associated with
adding partially non-conforming ones. Therefore I’d like to ask if we can
remove that functionality now that we have our own 'Vector' (I can do the
work if you prefer as I know your focus is understandably on other things).
*Future:*
It will be easily possibly to alter the current implementation to use es6
proxy which would likely provide the most reliable way to get full Vector
conformance indistinguishable from flash. Es6 proxy is transparent for
Array:
var p = new Proxy(new Array(), {});
Array.isArray(p) // true
This should allow trapping things like the length setter before it gets to
the underlying Array target, and doing checking for fixed == true etc. The
same is true for numeric index-based assignment of values etc.
es6 Proxy is kinda cool. At the moment IE11 is the only meaningful target
that does not support this.
I am only mentioning this here because I did think about this, and I
believe that the current implementation could be upgraded quite easily to
use this approach if it makes sense (when IE11 is a distant memory –
perhaps sometime next year!).
Phew, you made it! Well done.
Feel free to share your thoughts or ask any questions you might have. If
you have neither of those at this time, please still try to find time to
test any large projects you have in the branch, and provide feedback or
share any concerns you might have after doing that.
thanks,
Greg
On Thu, May 23, 2019 at 7:55 PM Greg Dove <gr...@gmail.com> wrote:
> Re XMLTest manualtest...
>
> Yep those were the ones I ported, Harbs. I think I got them all but may
> have missed some. I added a bunch more as well. Hopefully these can be
> easily migrated to what Josh has been working on.
>
>
> On Thu, 23 May 2019, 19:43 Harbs, <ha...@gmail.com> wrote:
>
>> As far as XML unit tests go, the starting point should be XMLTest in
>> manual tests. (Almost) every time I ran into an issue, I added it to that
>> project.
>>
>> I think I might have been lax on the last few issues I fixed, so we
>> should probably go through the later XML commits and make sure we have
>> tests for that.
>>
>> As far as Node goes, I think we probably need conditional Node
>> compilation to handle Node-specific (and browser specific) code in a PAYG
>> way.
>>
>> To technically handle the parsing, something like
>> https://github.com/isaacs/sax-js <https://github.com/isaacs/sax-js> is a
>> good starting point and something like this
>> https://github.com/nfarina/xmldoc <https://github.com/nfarina/xmldoc>
>> might be useful to either use or modify.
>>
>> Harbs
>>
>> > On May 23, 2019, at 10:18 AM, Greg Dove <gr...@gmail.com> wrote:
>> >
>> > All, I started porting some adhoc XML tests to UnitTests and eventually
>> > ended up spending quite a bit of time on addressing issues that arose
>> for
>> > XML before getting back to Vector stuff.
>> > I think XML probably needs many more unit tests before we get to 1.0
>> > because it has an extensive api. I have not used royale with Node yet,
>> but
>> > XML also needs some thought about how to get it working on Node, I
>> assume.
>> > Because XML uses the browser's parser and Node does not have one by
>> > default, then using the same code will need something to take the place
>> of
>> > the browser's native parser for Node. There is a lib in npm that might
>> be
>> > useful for that, but I don't know how that might work with licence etc.
>> > Anyhow, that is just an observation, I will focus on Vector in this
>> > thread... I will post here late tomorrow local time with more info, and
>> > discussion points. I am keen to see this merged in, but also keen to get
>> > buy-in first.
>> >
>> >
>> > On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <carlosrovira@apache.org
>> >
>> > wrote:
>> >
>> >> 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 (<gr...@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 <gr...@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 <ah...@adobe.com.invalid>
>> >>>> wrote:
>> >>>>
>> >>>>> +1 to renaming the options to the positive.
>> >>>>>
>> >>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <jo...@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 <gr...@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
>> >>
>>
>>
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
Re XMLTest manualtest...
Yep those were the ones I ported, Harbs. I think I got them all but may
have missed some. I added a bunch more as well. Hopefully these can be
easily migrated to what Josh has been working on.
On Thu, 23 May 2019, 19:43 Harbs, <ha...@gmail.com> wrote:
> As far as XML unit tests go, the starting point should be XMLTest in
> manual tests. (Almost) every time I ran into an issue, I added it to that
> project.
>
> I think I might have been lax on the last few issues I fixed, so we should
> probably go through the later XML commits and make sure we have tests for
> that.
>
> As far as Node goes, I think we probably need conditional Node compilation
> to handle Node-specific (and browser specific) code in a PAYG way.
>
> To technically handle the parsing, something like
> https://github.com/isaacs/sax-js <https://github.com/isaacs/sax-js> is a
> good starting point and something like this
> https://github.com/nfarina/xmldoc <https://github.com/nfarina/xmldoc>
> might be useful to either use or modify.
>
> Harbs
>
> > On May 23, 2019, at 10:18 AM, Greg Dove <gr...@gmail.com> wrote:
> >
> > All, I started porting some adhoc XML tests to UnitTests and eventually
> > ended up spending quite a bit of time on addressing issues that arose for
> > XML before getting back to Vector stuff.
> > I think XML probably needs many more unit tests before we get to 1.0
> > because it has an extensive api. I have not used royale with Node yet,
> but
> > XML also needs some thought about how to get it working on Node, I
> assume.
> > Because XML uses the browser's parser and Node does not have one by
> > default, then using the same code will need something to take the place
> of
> > the browser's native parser for Node. There is a lib in npm that might be
> > useful for that, but I don't know how that might work with licence etc.
> > Anyhow, that is just an observation, I will focus on Vector in this
> > thread... I will post here late tomorrow local time with more info, and
> > discussion points. I am keen to see this merged in, but also keen to get
> > buy-in first.
> >
> >
> > On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <ca...@apache.org>
> > wrote:
> >
> >> 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 (<gr...@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 <gr...@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 <ah...@adobe.com.invalid>
> >>>> wrote:
> >>>>
> >>>>> +1 to renaming the options to the positive.
> >>>>>
> >>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <jo...@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 <gr...@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
> >>
>
>
Re: Language improvements
Posted by Harbs <ha...@gmail.com>.
As far as XML unit tests go, the starting point should be XMLTest in manual tests. (Almost) every time I ran into an issue, I added it to that project.
I think I might have been lax on the last few issues I fixed, so we should probably go through the later XML commits and make sure we have tests for that.
As far as Node goes, I think we probably need conditional Node compilation to handle Node-specific (and browser specific) code in a PAYG way.
To technically handle the parsing, something like https://github.com/isaacs/sax-js <https://github.com/isaacs/sax-js> is a good starting point and something like this https://github.com/nfarina/xmldoc <https://github.com/nfarina/xmldoc> might be useful to either use or modify.
Harbs
> On May 23, 2019, at 10:18 AM, Greg Dove <gr...@gmail.com> wrote:
>
> All, I started porting some adhoc XML tests to UnitTests and eventually
> ended up spending quite a bit of time on addressing issues that arose for
> XML before getting back to Vector stuff.
> I think XML probably needs many more unit tests before we get to 1.0
> because it has an extensive api. I have not used royale with Node yet, but
> XML also needs some thought about how to get it working on Node, I assume.
> Because XML uses the browser's parser and Node does not have one by
> default, then using the same code will need something to take the place of
> the browser's native parser for Node. There is a lib in npm that might be
> useful for that, but I don't know how that might work with licence etc.
> Anyhow, that is just an observation, I will focus on Vector in this
> thread... I will post here late tomorrow local time with more info, and
> discussion points. I am keen to see this merged in, but also keen to get
> buy-in first.
>
>
> On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <ca...@apache.org>
> wrote:
>
>> 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 (<gr...@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 <gr...@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 <ah...@adobe.com.invalid>
>>>> wrote:
>>>>
>>>>> +1 to renaming the options to the positive.
>>>>>
>>>>> On 5/6/19, 8:12 AM, "Josh Tynjala" <jo...@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 <gr...@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
>>
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
All, I started porting some adhoc XML tests to UnitTests and eventually
ended up spending quite a bit of time on addressing issues that arose for
XML before getting back to Vector stuff.
I think XML probably needs many more unit tests before we get to 1.0
because it has an extensive api. I have not used royale with Node yet, but
XML also needs some thought about how to get it working on Node, I assume.
Because XML uses the browser's parser and Node does not have one by
default, then using the same code will need something to take the place of
the browser's native parser for Node. There is a lib in npm that might be
useful for that, but I don't know how that might work with licence etc.
Anyhow, that is just an observation, I will focus on Vector in this
thread... I will post here late tomorrow local time with more info, and
discussion points. I am keen to see this merged in, but also keen to get
buy-in first.
On Fri, May 10, 2019 at 11:15 PM Carlos Rovira <ca...@apache.org>
wrote:
> 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 (<gr...@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 <gr...@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 <ah...@adobe.com.invalid>
> > > wrote:
> > >
> > >> +1 to renaming the options to the positive.
> > >>
> > >> On 5/6/19, 8:12 AM, "Josh Tynjala" <jo...@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 <gr...@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
>
Re: Language improvements
Posted by Carlos Rovira <ca...@apache.org>.
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 (<gr...@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 <gr...@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 <ah...@adobe.com.invalid>
> > wrote:
> >
> >> +1 to renaming the options to the positive.
> >>
> >> On 5/6/19, 8:12 AM, "Josh Tynjala" <jo...@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 <gr...@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
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
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 <gr...@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 <ah...@adobe.com.invalid>
> wrote:
>
>> +1 to renaming the options to the positive.
>>
>> On 5/6/19, 8:12 AM, "Josh Tynjala" <jo...@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 <gr...@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.
>> >
>>
>>
>>
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
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 <ah...@adobe.com.invalid> wrote:
> +1 to renaming the options to the positive.
>
> On 5/6/19, 8:12 AM, "Josh Tynjala" <jo...@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 <gr...@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.
> >
>
>
>
Re: Language improvements
Posted by Alex Harui <ah...@adobe.com.INVALID>.
+1 to renaming the options to the positive.
On 5/6/19, 8:12 AM, "Josh Tynjala" <jo...@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 <gr...@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.
>
Re: Language improvements
Posted by Josh Tynjala <jo...@apache.org>.
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 <gr...@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.
>
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
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 <ca...@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 (<ha...@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 <gr...@gmail.com> wrote:
> > >
> > > Hi Harbs, a real quick answer inline below.
> > >
> > >
> > > On Sun, 26 May 2019, 20:39 Harbs, <ha...@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 <gr...@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
>
Re: Language improvements
Posted by Carlos Rovira <ca...@apache.org>.
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 (<ha...@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 <gr...@gmail.com> wrote:
> >
> > Hi Harbs, a real quick answer inline below.
> >
> >
> > On Sun, 26 May 2019, 20:39 Harbs, <ha...@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 <gr...@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
Re: Language improvements
Posted by Harbs <ha...@gmail.com>.
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 <gr...@gmail.com> wrote:
>
> Hi Harbs, a real quick answer inline below.
>
>
> On Sun, 26 May 2019, 20:39 Harbs, <ha...@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 <gr...@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.
>>
>>
Re: Language improvements
Posted by Greg Dove <gr...@gmail.com>.
Hi Harbs, a real quick answer inline below.
On Sun, 26 May 2019, 20:39 Harbs, <ha...@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 <gr...@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.
>
>
Re: Language improvements
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
to the risk to simplify it too much, the background is: AS3 Vector is still
missing in Royale, Greg work in an implementation. He consider AS3 Vector
an intrinsic part of the language, as String, Number, Object, Array, and
others. Alex would want Vector to be PAYG so we users can choose between
different implementations.
El dom., 26 may. 2019 a las 10:39, Harbs (<ha...@gmail.com>) escribió:
> 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?
>
> Thanks,
> Harbs
>
>
> > On May 5, 2019, at 11:00 AM, Greg Dove <gr...@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
Re: Language improvements
Posted by Harbs <ha...@gmail.com>.
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?
Thanks,
Harbs
> On May 5, 2019, at 11:00 AM, Greg Dove <gr...@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.