How do you store a String, or any random class, in Uint8Array? - Josh
On 2019/06/14 20:31:28, Alex Harui <[email protected]> wrote: > IMO, I would not expect the edge cases around "abstract" and "private" to > impact future language features as those are only allowed as "decorators" on > definitions and those features, from a language standpoint, allowed new > keywords where the grammar already allowed keywords. > > My concern around proposals for TypedArrays such as Array.<int> or int[] are > that those patterns can show up in a lot more places and if we don't pick the > right syntax, we'll be sorry later when we try to do typed function > signatures or generics or something else. AIUI, you have to think through > where else ".", "<", ">", "[" and "]" are used in the language and make sure > your new use for them won't cause conflicts now, or even worse, in the > future. And consider the general usability and coercion rules and probably > other things that I don't even know to consider since I am not a language > designer. Sure, Vector already uses ".<>", but it appears those uses are > mapped to a special construct in the compiler, and that's why my suggestions > for TypedArrays try to provide directives for the output of that construct > instead of adding a new construct until we are sure that other future plans > won't be compromised by how we support TypedArrays now. > > For example, the name Vector implies one-dimension to me. But I could > imagine folks wanting to add support for multi-dimensional Arrays. Or the > equivalent of Java Maps. > > Or, what will be the proposed literal for Typed Arrays if you use > Array.<int>? Will it be the same or different from Vector literal? > > For sure, I don't think there is anybody active in the project who is opposed > to supporting new language features like generics, typed functions and typed > arrays. I'm just asking questions to make sure we really need this work done > now instead of doing something cheaper and make sure folks who do work on it > think through the future implications of it. > > We already use directives to make "promises". For example, when you use > @royaleignorecoercion, you promise that no code paths will actually depend on > that coercion, you just added the coercion to keep the compiler from > complaining. And if it turns out you needed it, you'll end up with a bug. > We could do something similar now like @royaleusetypedarrayforthisvector and > if other code ends up turning off the "fixed" property and push stuff you'll > end up with a bug. I think that would only take someone a week or less. > > Or as I asked earlier, why can't folks just use Uint8Array? > > HTH, > -Alex > > On 6/14/19, 11:08 AM, "Josh Tynjala" <[email protected]> wrote: > > I definitely understand your concern about potentially missing edge > cases, and having that cause problems in the future. That's why I've been > trying to make new language features disabled by default so that folks need > to knowingly opt in. > > In my opinion, we should have left abstract classes and private > constructors disabled by default for a while, until more people could give > them a try. These features haven't even been included in an official release > yet. While I have a pretty good set of unit tests for each one, I'm sure that > there are still some edge cases that I'll need to address in the future. > > - Josh > > > On 2019/06/14 17:39:53, Alex Harui <[email protected]> wrote: > > IMO, it will be a significant amount of work to provide new syntax > around typed collections to ActionScript. I cannot help here because I am > not a language expert. Having interacted briefly with the ActionScript > language team, I am certain I do not have the skills to help here and am > concerned that we'll miss something and be sorry later. > > > > So, as long as folks are aware of that and still want to go forward, > I'm not going to stand in their way. I am going to suggest easier ways that > might save some time because I think there are bigger fish to fry with the > limited folks we have contributing to Royale. I'd rather see a quick way of > allowing folks to use TypedArrays to see how useful/important it is and then > see if we can make Royale successful and recruit someone with language design > experience. > > > > IOW, creating the general case implementation starting now may not be > in the best interests of the project. I would rather we make migrating Flex > code easier/faster, and those folks may not have time to consider changing > their code to switch to TypedArrays. > > > > Just from some quick thinking, I would say that getting the parser to > handle some new syntax is only 25% of the work. Another 10% is in getting > the output right for JS, but the remaining 65% is handling semantics, > ambiguity, and output to other runtimes. > > > > Also, since Array is "final", I think it would be more work to support > Array.<int> than TypedArray.<int>. And probably even easier just to support > the exact same classnames and APIs that JavaScript supports today. Is there > some reason that Uint8Array doesn't work today? > > > > I'd prefer that we take the time to find an expert to help us really > think through how we will implement generics in general in AS someday, and > handle Typed Arrays as an initial implementation on that path so we don't > later go "oh crap, if we hadn't picked this particular syntax for typed > arrays, our generics support would be so much simpler!". I just know I > cannot help here, but I caution against just copying what Java or Typescript > does. I think there are patterns in ActionScript that are different from > Java and TS that might factor in. > > > > So, go for it if you want, but please consider future ramifications. > > > > -Alex > > > > On 6/12/19, 5:20 PM, "Greg Dove" <[email protected]> wrote: > > > > Alex, javascript TypeArrays are fixed length at construction, so I > really > > don't think that can work in general case for drop-in substitution > of > > numeric Vector without some sort of wrapper class that supports > swapping > > things out. > > I really think that dedicated 'fast' numeric collection types will > likely > > need their own cross-target classes. > > It would work for a Vector that has a fixed = true constructor arg > and then > > never changes its 'fixed' status (and therefore never changes its > length > > also) and also only uses index access and assignments (no push, pop > etc), > > but it's a pretty restrictive scenario. I did look at this already. > > It might also be possible to map default Vector numeric types to > 'faster' > > versions for the 3 types, as an opt-in to the default > implementation's > > approach. I do plan to work on/investigate this later this month, > because I > > am keen to see performance-oriented options here too. But I was > thinking > > they would likely be separate, dedicated classes. > > > > > > On Thu, Jun 13, 2019 at 11:27 AM Alex Harui > <[email protected]> > > wrote: > > > > > FWIW, I would expect any syntax changes to be a significant > amount of work > > > especially where the BURM does the semantic checks. New BURM > patterns are > > > probably required. Or maybe it is time to get the BURM out of the > > > semantic-check business for JS (and maybe SWF) output and figure > out how to > > > do the semantic checks from the JS AST walk. > > > > > > Did you out finding a way to indicate that some Vector.<int> > should be > > > implemented as a TypedArray? > > > > > > -Alex > > > > > > On 6/12/19, 3:18 PM, "Josh Tynjala" <[email protected]> > wrote: > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
