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 <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 >> >> >>
