Alex, I made some comments inline below... On Thu, May 30, 2019 at 9:47 AM 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. > 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" <[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 > > >
