Hi Alex, this will be my last message in this thread. "The whole point of giving choices is to avoid having to spend so many emails trying to reach a decision. " Alex, I really don't understand your stance. The focus of the recent discussion has been on the choices themselves... concerns about their potential risks, along with ideas for improvements and code quality. It sounds like you are saying that we can't talk about improving the choices we already had, because if they exist that is all that matters. As far as I understand, the point of these email discussions is to reach the best quality collaborative decisions. I don't enjoy the process myself. It's inefficient. But we have an obligation to be collaborative (I think?). Expressing something along the lines of 'just do it and move on' does not seem to be that. I don't care about any of these things in terms of how it affects me personally, I have only pursued the topic in relation to what I think will help Royale be successful.
The only way I can interpret your replies thus far is: More options for optimization are always better, even if they might present possible risks that could harm the community. We deal with those risks by issuing warnings. Specifically, in this case, a library developer being able to dictate certain optimization(s) that should be used by (and any associated risks that should be accepted by) the application developer is not unacceptable. -Your approach to mitigation of the above risks will be for us to warn people not to do the specific things that could cause the problems in the first place (from your comment about tools, risks, and documentation). Something like: 'Don't use any emulation classes in library code unless your emulation class is Array, and if it is Array, don't expose the Vector type on any public or protected api surface because it will be a misleading representation of the type to the user of that api' Is that a fair summary? It should be not surprise to you that I personally think the above is confusing and avoidable, because I consider that there are (and will be) better options that achieve the same optimization results. But I understand that you don't, and I can accept that. So I will make one last attempt to find something that I think is middle ground... Vector-as-Array is just a special case of the emulationClass approach. The only middle ground I can think of with regard to reducing the risk is to have the 'emulationClass' approach is to actually re-map the type in the javascript output, so the swc typing actually represents the type it has been transformed to. This means if people don't follow the above instructions and the type is exposed on an api surface then it is not misrepresented to unsuspecting users via the swc that has the optimization. Does that make any sense? I have no idea at this point if this is easy to do or not. But it would address the main things that worry me about this (again, not for me, for royale in general). I only got to this idea out of frustration, although perhaps it could be considered obvious in retrospect. I'm not able to tackle this in the near term but I will be happy to pursue it at some point if you can agree it is a good compromise ( I hope it might be). As I said, I won't continue any more in this thread. If you like it please let me know, otherwise I officially give up. For now, I will try to find time to add the Vector-as-Array back in sometime later this week. I will do it inside the vectorEmulationClass code branches in the compiler as a special case of ' vectorEmulationClass '. Once I have that done and working I will merge. On Sat, Jun 1, 2019 at 8:26 AM Alex Harui <aha...@adobe.com.invalid> wrote: > Greg, you are still trying to use the language conformance argument. This > is not an issue of language conformance, it is an issue of optimization. > Code paths not needed should not be downloaded. Every app development tool > I've used that offers optimizations offers optimization levels and > documentation of risks. > > There is a disagreement on how to implement Vector in JS as well. The > whole point of giving choices is to avoid having to spend so many emails > trying to reach a decision. Just provide choices so we can move on. Every > argument you make below is an argument for giving choices. > > -Alex > > On 5/30/19, 9:03 PM, "Greg Dove" <greg.d...@gmail.com> wrote: > > "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 does not prove that at all, Alex. It depends on the criteria, and we > have no commonly accepted guiding principles for what is 'right' here. > At least one of us believes that it is more correct that (in the > absence of > other proposed options) it be an Array in the original code. > If you take a step back and look at it from a broader perspective, it > can > be equally true to say 'This agreement proves that the original > implementation was not right'. > Firstly, I don't think Vector type was providing any benefit in this > case > in the first place (but that alone is not a reason to change it, > awareness > that it 'costs more' would however be a valid reason if there are no > benefits to using it). > Secondly, the collaborative outcome resulting in the use of explicit > Array > and the goog.DEBUG check is better than the original Vector-as-Array > output > because it offers the runtime type safety that was missing because it > was > not behaving like a Vector - and it retains the advantage of > zero-weight in > release build. Making these changes *is* a form of optimization based > on > using options currently available, it just happens to be hand-coded > and not > compiler-generated. > I know it's at least a little bit useful in its new form, because prior > testing with the branch level Vector implementation flagged a > non-conforming IBead in the 2nd app I tested it with, something that > was > not found by the original 'Array' implementation. > SWF testing in parallel would have caught that too, but is not a > realistic > assumption to have that as part of the workflow for checking runtime > behavior anymore, so this 'Array with debug-only typecheck' in > javascript > is a good outcome. > In this case, going back to Vector-as-Array output without making the > other > change would be a step backwards. > > That is however just one specific case, and I needed to present what I > believe is a more balanced view of that... but I will not focus on it > in > any further discussion. > I do understand that your point is intended to be more general. > In general, and *by definition*, the cases where you want Vector to be > Array without adverse consequences are always cases where it can also > *be* > Array in the original as3 code. If the only justification for it being > a > Vector in as3 code is 'compile-time type safety', then the proposed > alternative from Harbs and Josh is a better option because it retains > the > benefits you seek and is a better quality cross-target representation > for > this specific sort of requirement (it will also provide more benefits: > most > Vector methods do not have compile-time type safety because most their > method signatures do not specify :T types, I hope the proposed > alternative > might address that). > For the performance-oriented numeric types, which is another thing > that has > been raised, maybe Josh can somehow include that with the typed Arrays > feature as he suggested, maybe not. If yes, then great, but if not, I > am > happy to explore other options for that. > > What I'd really like to hear are your thoughts about the concerns I > raised > for the: > "new whateverclasstheconfigordirectivespecified()" > approach to doing any of this. > > How do you propose to avoid risk to the community and potentially to > Royale's reputation with release of swcs that can have different > language-level variations in them (XML, Vector or anything that > represents > a core as3 'type')? > Do we have to warn people not to do that, and then hope that they > don't? A > user of that swc doesn't see the emulation class that the swc may > expose > without investigating at runtime, they normally only see the type it > represents, and unless they are warned, they have no reason to assume > it > won't do all the things it should. There could also be runtime conflict > implications when mixing swcs with different emulation decisions, and > that > could even add weight overall compared to using one. None of this > represents stuff that can't be figured out and addressed by developers > who > have to deal with it. But it seems to me to be something negative, > which > would be better to avoid. > > I think you are indicating the same desire to avoid this problem by > saying > that you want to specify things by 'the swc' you add (e.g. XML > replacement)... but that can be too late, because even if an alternate > emulation class itself is not bundled into a swc's code, all the calls > to > instantiate it are, which reflect its distinct package name and class > name. > I can envisage ways to achieve optimization and to avoid risks for the > general case, but only if the instantiation calls for these language > level > emulations can never vary throughout the entire codebase (all swcs > included), and the 'optimization' is therefore largely driven from the > application build, and not dictated at swc level. Maybe swc libraries > could > be advertised as being compatible with some well-known optimizations in > this case, it could even be a 'marketing' claim for the swc. > The most appealing optimization solution (to me) would be one that > takes > more advantage of GCC (which I consider will be 'safer', and also least > effort for the developer) when the application gets built, instead of > actually changing the content of individual methods (for example) in > 'lite' > versions of replacement classes. However, I can see that doing the > latter > (or both) should also be possible and should not be much different, I > think, from a regular monkey-patch approach, or from your desire for > swc > level replacement - but it only works if there is no variation in the > actual naming of the classes that are being 'patched' (whether its via > an > alternate XML-like swc as a direct substitute for the standard one, or > a > local monkey patch). Maybe I'm missing something that is obvious to > you... > please tell me if I am. > > > On Fri, May 31, 2019 at 6:37 AM 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> > 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%7C7b5824f745304f9e222308d6e57cfac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948722282899722&sdata=T5XYilhl3fSjVqu60ZolwQWXIczCR5w73axIKMd%2BDS0%3D&reserved=0 > > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > -- > > Carlos Rovira > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C7b5824f745304f9e222308d6e57cfac1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636948722282899722&sdata=T5XYilhl3fSjVqu60ZolwQWXIczCR5w73axIKMd%2BDS0%3D&reserved=0 > > > > > > > > >
