I have limited time and Google Docs was easiest. If someone else wants to spend time making wiki entries, that’s great.
Thanks, Harbs > On Jan 13, 2019, at 12:04 PM, Carlos Rovira <[email protected]> wrote: > > I think as well will be better to bring that document to the wiki and > invite all people review and contribute > Is more an "official place" > thanks > > El vie., 11 ene. 2019 a las 18:46, Alex Harui (<[email protected]>) > escribió: > >> I would like to know why you are using Google Docs and not the wiki. IMO, >> unless folks on dev@ can follow discussion from comments in Google Docs, >> we should not be using Google Docs. >> >> IMO, structured programming constructs in AS3 separate us from most other >> JS app-building choices. We should be striving to make the use of >> structure more efficient and not encouraging the use of >> unstructured/dynamic constructs. Olaf had a good point about some of >> these features being about writing low-level JS. Folks writing >> future-proof apps really shouldn't be calling JS/Browser classes directly. >> We should be wrapping those things into proper abstractions. IOW, if you >> instantiate a Blob, you are giving up portability. If you instantiate a >> BinaryData then you are not. Underneath, we can do certain things to make >> the writing of the platform implementation by framework developers more >> efficient, but really, we shouldn't be encouraging users of Royale to also >> write to those low-level JS APIs. Otherwise, folks are likely going to get >> in the same trouble they are with Flex. No large app has shown up to be >> migrated that did not use flash.*.* classes and only used Flex classes that >> hid the low-level Flash stuff and where those migrating used Flash, that is >> really holding up their migration effort. I don't think we should >> encourage users to use low-level JS APIs and have the same problem if we >> target something else someday. It is pretty safe to assume that every >> future platform/runtime will support a binary array of data, but it >> unlikely they will support initializing that class with an object literal. >> >> Also, IMO, Royale is more about a toolchain/workflow than a framework. >> Really, we are trying to be framework agnostic. We want to leverage >> structure in the language to allow the IDEs to be better than any >> JS-oriented IDE. >> >> As such, it is worth considering whether some of these ideas, especially >> type-inferencing, should be done in the IDEs instead of the compiler. The >> compiler will never be fast enough, so the more we make it think on every >> compile, the less productive you are. Also look at really advanced IDEs >> for structured languages. Do those JAVA IDEs support inferencing types >> from literals? Why has the Java compiler decided not to inference types >> from literals? At least, I don't think it does. Usually there is a good >> reason behind these decisions that we should consider. >> >> IMO, we want to put most of our energy into separating us from the pack >> not being more like the pack. >> >> My 2 cents, >> -Alex >> >> >> On 1/11/19, 4:27 AM, "Harbs" <[email protected]> wrote: >> >> I started a separate document with thoughts on typedefs. >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1gQTI08o5OJwawpludknyAX8oaa7quOZP9fridJWsKgg%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Caharui%40adobe.com%7Cffce206667d3415e498b08d677c015fc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636828064220720562&sdata=6RZNncFtAGeyT8hBBNXxq0G9yPI6yLDAJkUCY%2B908eg%3D&reserved=0 >> < >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1gQTI08o5OJwawpludknyAX8oaa7quOZP9fridJWsKgg%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Caharui%40adobe.com%7Cffce206667d3415e498b08d677c015fc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636828064220720562&sdata=6RZNncFtAGeyT8hBBNXxq0G9yPI6yLDAJkUCY%2B908eg%3D&reserved=0 >>> >> >> The doc is editable. Feel free to add to it and make changes and >> corrections. >> >> It’s possible there is currently a way to specify source externs that >> I’m not aware of. >> >> My goal with my typedef thoughts are: >> 1. Make typedefs easier to use. >> 2. Improve type safety and easy of use with literal objects and JSON. >> 3. Produce reliable output even after minification. >> >> Thanks, >> Harbs >> >>> On Jan 11, 2019, at 4:39 AM, Alex Harui <[email protected]> >> wrote: >>> >>> FWIW, we already support source externs. >>> >>> On 1/10/19, 2:38 PM, "Harbs" <[email protected]> wrote: >>> >>> I very much would like for AS3 to get an upgrade with features. >> That applies to improvements I the compiler output as well as truly new >> features in the language. >>> >>> I’ve started some discussion with Josh on the topic, and we >> started a Google doc to use to help figure out how we can incrementally >> improve things. >>> >>> The link to the Google Doc is here: >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F188AAeny3y7bht9JbuE-RXIF_adZHP5uYj0--RANpGNM%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Caharui%40adobe.com%7Cffce206667d3415e498b08d677c015fc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636828064220720562&sdata=zgfXOasbwzADcuofrjyY%2FL1ppCUpucngpeVQ8vhOSwY%3D&reserved=0 >> < >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F188AAeny3y7bht9JbuE-RXIF_adZHP5uYj0--RANpGNM%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Caharui%40adobe.com%7Cffce206667d3415e498b08d677c015fc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636828064220720562&sdata=zgfXOasbwzADcuofrjyY%2FL1ppCUpucngpeVQ8vhOSwY%3D&reserved=0 >>> >>> >>> I enabled commenting. If someone wants edit access to the >> document, please let me know. >>> >>> Thanks, >>> Harbs >>> >> >> >> >> > > -- > Carlos Rovira > http://about.me/carlosrovira
