To me there are (or rather will be) two kinds of “Vector”. 1. `Vector.<Foo>` (which has the extra code) 2. `Foo[]` which would have no extra code.
Do you have a reason why you’d want to use `Vector.<Foo>` rather than `Foo[]`? Having two completely different constructs seems like it would be much less confusing for users. Harbs > On May 30, 2019, at 9:36 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > It is pretty simple to me. The proposed Vector implementation is heavy > enough that we all agree that we don't want to use it for just one use case > in the Strand. And so we will stop using Vector and migrate to using a plain > Array. That agreement proves that the proposed changes are not right. We > will effectively encourage others to do the same. > > It would be much better if Royale had a way for developers to specify that > the one use of Vector in the Strand should be converted to plain Array by the > compiler and other uses could use the proposed Vector. That's how > optimization should be made available for all kinds of code in Royale, not > just for Vector. > > The current Vector output in the develop branch is low cost and fully > functional for some uses cases. As long as that output is still available as > a compiler option then having other output fine. > > I still haven't found time to look at the actual proposed changes, but I > would strongly prefer that, instead of having to modify compiler output each > time someone proposes a different Vector implementation, that the changes can > all be done by which SWC you choose for your Vector implementation. There > are other places in the compiler where you can choose the class to use for > Binding or ClassFactory. Hopefully the same approach is being used for > Vector. Ideally, the compile would just output "new > whateverclasstheconfigordirectivespecified()" and then just output the usual > push/pop/index calls and so it could just be plain Array where specified or > the proposed Vector and some other Vector someday. > > This is a case were "there is no one right way". And when we have those > situations, we must offer choices. > > -Alex > > On 5/30/19, 1:34 AM, "Carlos Rovira" <carlosrov...@apache.org > <mailto:carlosrov...@apache.org>> wrote: > > 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%7Cce57a3320feb49da636d08d6e4d9a71d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948020835204701&sdata=4u4%2FZXFJMhdghUaW9itlH89m6HGPhe34pSHdrECJnT8%3D&reserved=0 >> >> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cce57a3320feb49da636d08d6e4d9a71d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948020835204701&sdata=4u4%2FZXFJMhdghUaW9itlH89m6HGPhe34pSHdrECJnT8%3D&reserved=0> >>>>> >>>>> >>>>> >>> >>> >> > > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cce57a3320feb49da636d08d6e4d9a71d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948020835204701&sdata=4u4%2FZXFJMhdghUaW9itlH89m6HGPhe34pSHdrECJnT8%3D&reserved=0 > > <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cce57a3320feb49da636d08d6e4d9a71d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948020835204701&sdata=4u4%2FZXFJMhdghUaW9itlH89m6HGPhe34pSHdrECJnT8%3D&reserved=0>
