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