Hi, @Alex Harui <aha...@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.d...@gmail.com>) escribió: > Harbs some quick comments inline... > > On Thu, May 30, 2019 at 4:27 PM Harbs <harbs.li...@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 <joshtynj...@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 <aha...@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" <carlosrov...@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.li...@gmail.com>) > > escribió: > > >> > > >>> > > >>>> On May 28, 2019, at 11:12 AM, Greg Dove <greg.d...@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
