I plan to start out by supporting Array.<T> syntax, similar to Vector.<T>. Like you said, there are advantages to using the same syntax for all typed collections.
Later, I'll see if I can figure out how to add T[] syntax as an alternative, since Harbs seems to like that better. - Josh On 2019/06/12 20:14:50, Greg Dove <[email protected]> wrote: > Hey Josh, > > Thanks for looking into that, I figured it could be a bit tricky! Good luck > with it. > I think you and Harbs were maybe leaning to towards Number[] and String[] > type declarations. I don't mind either way, but perhaps the Array. with > angle brackets approach that is used for Vectors could make it easier to > swap between typed Array and Vector if people consider refactoring (and > whatever IDE they're using won't support more automated changes). OTOH, the > first approach is definitely easier to type. You probably already thought > those things through though, I guess. > > If you end up with a remote branch for your work on this at some point and > want someone to help with testing or anything like that, I'm in, just let > me know. > > > On Thu, Jun 13, 2019 at 2:26 AM Josh Tynjala <[email protected]> wrote: > > > > 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 > > > > > > > > > > > > > > > > > > >
