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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 (<[email protected]>) > escribió: > > > > > > > > > On May 28, 2019, at 11:12 AM, Greg Dove <[email protected]> > 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 > > > > > > >
