> I think your other proposal with Josh for the typed Arrays and their greater > compile-time safety will be a better fit for many cases as well, so I hope > that happens.
I started working on typed arrays this week. It may be a while before I can merge, though. It's definitely more complex than private constructors and abstract classes. - Josh On 2019/06/12 04:21:18, Greg Dove <[email protected]> wrote: > Hi Harbs - just in reply to your specific questions: > As I mentioned elsewhere it is easy to have full speed index access and > also full speed pop() and unshift() methods > If you switch off the first 3 settings I outlined in the post titled > 'Language/Reflection improvements details' you will have that. Those > settings are switchable locally with doc directives as well. I will do a > full write-up this coming weekend for docs. Hopefully I can harvest a lot > of what I already wrote elsewhere for that. > BTW I switched TLF to use the legacy Vector-as-Array approach by default, I > am not sure what you want there, you could undo that if you prefer. > > Beyond the above mentioned approaches for (mainly index level) > optimization, I have a preference for two more approaches, but I'd rather > limit the overall number of options to be what people definitely need > instead of adding too many options (which could create confusion). I think > your other proposal with Josh for the typed Arrays and their greater > compile-time safety will be a better fit for many cases as well, so I hope > that happens. If I have time to help out in any way with that, I would be > happy to do so as well, because it sounds like something I would use a lot. > Anyhow, I do want to support more optimizations with this implementation. > Can you say what your main concerns would be for optimization? Is it mainly > for 'push' (and unshift) ? Those would be mine... > > I would personally like to see the following: > > 1. A global optimization setting that affects all instances in all code > including pre-built library code. This would avoid certain runtime checks > and would also result in a lighter implementation. This is something the > final application developer decides, not anything dictated by a library > developer (but a library developer could advertise their public swc as > being compatible/safe with this type of optimization). This approach could > include perhaps 2 levels: one to remove any code paths related to fixed > length Vectors (which I think you said you never used) for example. Then > another possibly removing all element level type-checking as another level. > Adding this should not be too difficult I think and would be determined via > a goog define (which might be driven by a compiler setting, I did not look > at how easy this is yet). The thing I like about this approach is that it > is not 'baked-in' to any instance and the application developer makes the > ultimate decision and owns the associated risk (as opposed to having it > imposed on them by a library developer, for example). I think the removal > of support for 'fixed' Vectors could probably be made to generate > (debug-only) errors if there is code that runs that sets fixed to true on > any Vector instance - to provide some reassurance of no side effects when > choosing this option. > > 2. Compilation scoped optimizations. > By 'compilation-scoped' I mean configurable in the same way as the > vector-index-check suppression: An over-arching config setting for the > current compilation that can be overridden locally with doc comment > directives. This affects code sites (or all current compilation scope if > set in the config) and not specific instances. I would hope this might be > the only other 'Vector' specific config option like this, simply to avoid > confusion with too many options. > So I personally think the important things here are the push and unshift > methods, because they're the ones that are also most often used in loops > when index level access or assignment is not being used (in the loop). But > I'm keen to hear more about what people want in case it's different to how > I think. And I will add support for what best represents the needs of the > community. While index level access is best for large loops (just as it is > for 'Array'), push could be preferred in small loops because it does not > require a 'get' for length to establish the upper bound of the loop or the > next acceptable index to set (for non-fixed Vectors). The optimization for > push in this case would be to bypass runtime typechecking and just do a > regular Array.push into the underlying Vector representation, which is > still actually an Array in terms of how javascript sees it. Adding this > option is easy also, but rather than just forging ahead with it, I am keen > to get input from others first. > > I consider that specific instance level optimizations (in general) are > 'dangerous' because even if the code is 'safe' when it is originally > written, subsequent changes to the overall codebase (possibly by different > developers) can mean that an instance ends up elsewhere in code where it > behaves differently from other instances of the same type. Code-site > optimizations could also create an unusual internal state for an instance, > but most often they should not, because the code site where the > optimization is used should be validated in terms of the optimization by > its original developer (e.g. no runtime type checking at a particular usage > site because it is never needed in the context of that code, for example) > and the behavior of the same instance elsewhere should be much less of a > risk. > > More feedback from you or anyone else is definitely welcome for what they > want to see for optimization options of the implementation. I'm sure I can > still find more ways to improve the implementation for speed as it is now > as well, I can think of a one thing I want to investigate further. > -Greg > > > > > On Wed, Jun 12, 2019 at 1:54 AM Harbs <[email protected]> wrote: > > > Practical question for me is: How do we disable to Vector runtime > > checking? I was having trouble following the full discussion. My > > understanding was that there’s a compiler flag, but I’m not sure what it is. > > > > > On Jun 11, 2019, at 7:10 AM, Yishay Weiss <[email protected]> > > wrote: > > > > > > Language.js:868 [1] is > > > > > > if (elementType.indexOf('Vector.<') == 0) { > > > > > > > > > > > > ________________________________ > > > From: Yishay Weiss <[email protected]> > > > Sent: Tuesday, June 11, 2019 2:07:36 PM > > > To: [email protected] > > > Subject: Problem with Vectors > > > > > > Hi Greg, > > > > > > I just updated Royale and I’m seeing that in our class FontLoader > > > > > > private var _fonts:Vector.<Font> = new Vector.<Font>(); > > > > > > gets transpiled to > > > > > > this.com_printui_text_engine_FontLoader__fonts = > > org.apache.royale.utils.Language.Vector(); > > > > > > Notice how the type isn’t given in Vector’s constructor. This results in > > a runtime error [1]. Any ideas? > > > > > > [1] > > > > > > TypeError: Cannot read property 'indexOf' of null > > > Watch > > > Call Stack > > > org.apache.royale.utils.Language.VectorSupport.vectorElementCoercion > > > Language.js:868 > > > org.apache.royale.utils.Language.synthVector > > > Language.js:642 > > > org.apache.royale.utils.Language.Vector > > > Language.js:685 > > > com.printui.text.engine.FontLoader > > > FontLoader.js:24 > > > > > > > >
