I'm not disagreeing. I think the question is whether we need yet another compiler option to generate bracket notation for objects or just ask folks to use SIMPLE_OPTIMIZATIONS. And whether we switch to SIMPLE_OPTIMIZATIONS by default. I can think of lots of other things to work on besides this new option if we have rough equivalents.
-Alex On 2/8/18, 10:36 AM, "[email protected] on behalf of Carlos Rovira" <[email protected] on behalf of [email protected]> wrote: >Although I'm pro typed, I agree with Josh that we should not enforce >that. >That's one of the great points in Flash/Flex. >For make things quick, I use simple objects with bracket notation, when >the >application is more relevant I go the right typed path. >It's up to the developer decide when they want one or another. > > > >2018-02-08 18:50 GMT+01:00 Josh Tynjala <[email protected]>: > >> Nothing frustrated me more about Royale/FlexJS than the fact that I >> couldn't use untyped objects without bracket notation. It's a very bad >>user >> experience when trying to consume JSON, or even when choosing to create >>my >> own object literals. While it's a good best practice to create value >> objects, that shouldn't be forced on everyone. I frequently use untyped >> objects when prototyping because it's more convenient. They're also >>useful >> in example code to reduce boilerplate that isn't particularly relevant >>to >> the concept/feature that you're trying to demonstrate. And, of course, >> there's the already mentioned JSON. >> >> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS the >> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly >> larger file size is an acceptable trade off, if it reduces the >>frustration >> of this situation. Especially for new users who will absolutely think >>its a >> serious bug in the Royale compiler. However, as Harbs notes here, if the >> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be >>retained. >> The compiler could generate code differently when something resolves as >>the >> Object type. The emitter could translate dot notation normally most of >>the >> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it >> detects Object, switch to bracket notation instead. I believe it would >>also >> need to add quotes around properties defined in object literals. >> >> Ideally, the following code should work properly out of the box: >> >> var obj:Object = {one: 1, "two": 2}; >> obj.three = 3; >> obj["four"] = 4; >> var one:Number = obj["one"]; >> var two:Number = obj.two; >> var three:Number = obj["three"]; >> var four:Number = obj.four; >> >> The compiler would probably emit something like this to make it work >>with >> the Closure compiler's ADVANCED_OPTIMIZATIONS: >> >> var obj:Object = {"one": 1, "two": 2}; >> obj["three"] = 3; >> obj["four"] = 4; >> var one:Number = obj["one"]; >> var two:Number = obj["two"]; >> var three:Number = obj["three"]; >> var four:Number = obj["four"]; >> >> Again, that's only for when something is typed as Object. If something >> actually has a class, let Closure compiler go nuts and rename >>everything it >> wants. >> >> - Josh >> >> On 2018/02/06 08:51:19, Gabe Harbs <[email protected]> wrote: >> > Quite sure. In my angular app I was using an older version of the >> closure compiler to minify the js files. I was using the default options >> which clearly does not use ADVANCED_OPTIMIZATIONS, so the object >>literals >> didn’t get renamed. >> > >> > I think most modern app frameworks use other tools such as Babel for >> magnification, but I believe that handles object literals correctly too. >> > >> > We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing >> object literals. I’m proposing a compiler *option* to allow to continue >> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which >>should >> not be renamed. >> > >> > Harbs >> > >> > > On Feb 6, 2018, at 9:38 AM, Alex Harui <[email protected]> >> wrote: >> > > >> > > Are you sure Angular and React minify your code instead of running >>it >> > > against their minified framework? >> > > >> > > -Alex >> > > >> > > On 2/5/18, 11:22 PM, "Gabe Harbs" <[email protected]> wrote: >> > > >> > >>> Maybe I'm missing something. I don't think Royale has any extra >> > >>> problems >> > >>> with JSON objects than other JS Frameworks have. If you want to >> minify, >> > >>> you have to use brackets and strings. >> > >> >> > >> It does. >> > >> >> > >> I’ve written angular apps and I’ve never had to worry about using >> bracket >> > >> notation for minifying simple js objects. I’m pretty sure the same >>is >> for >> > >> React, etc. >> > >> >> > >>> On Feb 5, 2018, at 11:34 PM, Alex Harui <[email protected]> >> > >>> wrote: >> > >>> >> > >>> Maybe I'm missing something. I don't think Royale has any extra >> > >>> problems >> > >>> with JSON objects than other JS Frameworks have. If you want to >> minify, >> > >>> you have to use brackets and strings. If you don't want to >>minify, >> then >> > >>> you don't need to worry about that. Am I wrong about that? >> > >>> >> > >>> >> > >>> JSON has something like a "reviver". Has anyone played with that >>to >> see >> > >>> if it can be used to convert straight to VO's? >> > >>> >> > >>> Thanks, >> > >>> -Alex >> > >>> >> > >>> On 2/5/18, 1:08 PM, "Gabe Harbs" <[email protected]> wrote: >> > >>> >> > >>>> An additional point: >> > >>>> >> > >>>> How do you propose handling json that’s multiple levels deep? >>Walk >> the >> > >>>> json and construct VOs on each level? That seems to me just as >>bad >> as >> > >>>> the >> > >>>> problem. Imagine you just want foo.baz.thingy.uid? You’d need to >> > >>>> create a >> > >>>> VO of foo, baz and thingy or be forced to use >> > >>>> foo[“baz”][“thingy”][“uid”]. Of course the average user is not >> going to >> > >>>> remember to do that until their release build doesn’t work… >> > >>>> >> > >>>> Creating VOs means you can’t simply use JSON.parse(). You’d need >> your >> > >>>> own >> > >>>> parser for each type of json you’re consuming. OK. Maybe not full >> > >>>> parsing, but the constructors for these VOs will get pretty >>messy — >> > >>>> especially if the structure is a bit fluid. >> > >>>> >> > >>>> Harbs >> > >>>> >> > >>>> >> > >>>>> On Feb 5, 2018, at 10:36 PM, Gabe Harbs <[email protected]> >> wrote: >> > >>>>> >> > >>>>> In theory, everything you say is true. It might even be good >> practice. >> > >>>>> >> > >>>>> I’m telling you that this was a pain point when migrating my >>app. >> > >>>>> Simply declaring types as VOs didn't solve the problem for me. >>The >> way >> > >>>>> I’ve found that’s needed to solve the problem was passing the >> object >> > >>>>> literal into a VO constructor and declaring the variables using >> > >>>>> bracketed access. I was likely going about it wrong, but it was >> easier >> > >>>>> to just go with the bracketed literals. >> > >>>>> >> > >>>>> Again: Suggesting using VOs (if we can figure out easy >> instructions to >> > >>>>> do so) is probably a good idea and better recommended practice, >>but >> > >>>>> people live on the edge using other JS frameworks, and I’d >>rather >> not >> > >>>>> make it harder than it needs to be if they do want to use >>untyped >> > >>>>> object >> > >>>>> literals. >> > >>>>> >> > >>>>> Harbs >> > >>>>> >> > >>>>>> On Feb 5, 2018, at 8:01 PM, Alex Harui >><[email protected]> >> > >>>>>> wrote: >> > >>>>>> >> > >>>>>> It was great to skip type-checking in Flash at times, but the >> runtime >> > >>>>>> was >> > >>>>>> also strongly typed. Also, JS was not a practical language for >> > >>>>>> Flash. >> > >>>>>> It >> > >>>>>> is more risky to do skip type-checking in Royale for JS. These >> new >> > >>>>>> cars >> > >>>>>> with lane warnings are a rough analogy. They only let you be >>less >> > >>>>>> attentive on nice new painted highways. Flash's runtime >>wouldn't >> let >> > >>>>>> you >> > >>>>>> make type mismatches so it effectively had lane lines. JS is a >> road >> > >>>>>> without lane lines. A ValueObject keeps your eyes on the road. >> An >> > >>>>>> ounce >> > >>>>>> of prevention is better than a pound of cure. >> > >>>>>> >> > >>>>>> IMO, you might be better off writing a bead that you can pass a >> JSON >> > >>>>>> object and it will generate the AS class for you to copy from >>the >> > >>>>>> clipboard and paste into a file. Then you could guess at the >> types. >> > >>>>>> That >> > >>>>>> wouldn't require compiler changes and would encourage early >> > >>>>>> prevention. >> > >>>>>> >> > >>>>>> Just an idea, >> > >>>>>> -Alex >> > >>>>>> >> > >>>>>> On 2/5/18, 9:39 AM, "Gabe Harbs" <[email protected]> wrote: >> > >>>>>> >> > >>>>>>> Yeah. That’s what you’ve argued in the past, and in a pure >>world >> > >>>>>>> you’d be >> > >>>>>>> right. >> > >>>>>>> >> > >>>>>>> However, I’d prefer the option to be practical when dealing >>with >> > >>>>>>> more >> > >>>>>>> data types. Being forced to fiddle with properly typed objects >> > >>>>>>> *always* >> > >>>>>>> is too confining IMO. What I personally ended up doing when >> dealing >> > >>>>>>> with >> > >>>>>>> APIs and the like was the make sure to quote everything in my >>app >> > >>>>>>> rather >> > >>>>>>> than declare VOs even though finding all the instances were a >> pain. >> > >>>>>>> >> > >>>>>>> I think it’s pretty common for folks to use untyped objects >> > >>>>>>> *especially* >> > >>>>>>> when dealing with APIs in classic Flex apps. It seem overly >> > >>>>>>> draconian >> > >>>>>>> to >> > >>>>>>> make that a requirement for Royale. >> > >>>>>>> >> > >>>>>>> Part of the attraction of ActionScript has been that it’s >> > >>>>>>> *optionally* >> > >>>>>>> typed. Minification in JS makes the optional typing pretty >>weak. >> > >>>>>>> >> > >>>>>>>> If you don't care about SWF support, you can quickly make >> > >>>>>>>> ValueObjects >> > >>>>>>>> just for the compiler. >> > >>>>>>> >> > >>>>>>> Quickly? I’m not sure how. >> > >>>>>>> >> > >>>>>>> My $0.02. >> > >>>>>>> Harbs >> > >>>>>>> >> > >>>>>>>> On Feb 5, 2018, at 7:28 PM, Alex Harui >><[email protected] >> > >> > >>>>>>>> wrote: >> > >>>>>>>> >> > >>>>>>>> IMO, your proposal sort of defeats the purpose of >>ActionScript >> and >> > >>>>>>>> Royale, >> > >>>>>>>> which is to provide a type system at compile time. Not only >> should >> > >>>>>>>> you >> > >>>>>>>> want to address your JSON fields, but you should want to have >> them >> > >>>>>>>> type-checked, and that you spelled the field name correctly. >> > >>>>>>>> Otherwise, >> > >>>>>>>> the compiler is going to also allow you to mistype: >> > >>>>>>>> >> > >>>>>>>> var name = myProps["nme"]; >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> And there will be no errors. And similarly: >> > >>>>>>>> >> > >>>>>>>> var myObj:Object = { >> > >>>>>>>> nme: "foo", >> > >>>>>>>> age : 30.1415 >> > >>>>>>>> } >> > >>>>>>>> >> > >>>>>>>> Will be allowed when it probably shouldn't. And also, you >>could >> > >>>>>>>> then >> > >>>>>>>> use >> > >>>>>>>> myObj when you intended to use myOtherObj and nobody will >>know >> > >>>>>>>> until >> > >>>>>>>> you >> > >>>>>>>> try to debug in JS. >> > >>>>>>>> >> > >>>>>>>> >> > >>>>>>>> If you don't care about SWF support, you can quickly make >> > >>>>>>>> ValueObjects >> > >>>>>>>> just for the compiler. In ASDoc, the ValueObject is never >> > >>>>>>>> instantiated. >> > >>>>>>>> It is just like a typedef for the compiler. >> > >>>>>>>> >> > >>>>>>>> HTH, >> > >>>>>>>> -Alex >> > >>>>>>>> >> > >>>>>>>> On 2/5/18, 8:43 AM, "Gabe Harbs" <[email protected]> >>wrote: >> > >>>>>>>> >> > >>>>>>>>>> JSON Objects are not destroyed. >> > >>>>>>>>> >> > >>>>>>>>> Yeah. I know, but untyped js literals are pretty much >>useless >> in >> > >>>>>>>>> minified >> > >>>>>>>>> Royale apps. >> > >>>>>>>>> >> > >>>>>>>>>> Propose a way to determine that a data structure >> > >>>>>>>>>> is external and what the compiler should generate and >> implement >> > >>>>>>>>>> it. >> > >>>>>>>>>> IMO, >> > >>>>>>>>>> the answer is to create ValueObjects. That is essentially >> > >>>>>>>>>> typedefs >> > >>>>>>>>>> and >> > >>>>>>>>>> AFAIK, there is no way to automate typedef generation. >> > >>>>>>>>> >> > >>>>>>>>> I already made a suggestion once: >> > >>>>>>>>> >> > >>>>>>>>> For untyped Objects, the compiler could convert dot >>notation to >> > >>>>>>>>> bracket >> > >>>>>>>>> notation. >> > >>>>>>>>> >> > >>>>>>>>> The other half of that would be to convert all object >>literals >> to >> > >>>>>>>>> “quoted” literals automatically. >> > >>>>>>>>> >> > >>>>>>>>> So if I have a function: >> > >>>>>>>>> >> > >>>>>>>>> function parseMyJson(json:String):Object{ >> > >>>>>>>>> return JSON.parse(json); >> > >>>>>>>>> } >> > >>>>>>>>> >> > >>>>>>>>> var myProps:Object = parseMyJson(json); >> > >>>>>>>>> >> > >>>>>>>>> var name:string = myProps.name; >> > >>>>>>>>> >> > >>>>>>>>> Would become: >> > >>>>>>>>> >> > >>>>>>>>> function parseMyJson(json){ >> > >>>>>>>>> return JSON.parse(json); >> > >>>>>>>>> } >> > >>>>>>>>> >> > >>>>>>>>> var myProps = parseMyJson(json); >> > >>>>>>>>> >> > >>>>>>>>> var name = myProps["name"]; >> > >>>>>>>>> >> > >>>>>>>>> And this: >> > >>>>>>>>> var myObj:Object = { >> > >>>>>>>>> name: "foo", >> > >>>>>>>>> age : 30 >> > >>>>>>>>> } >> > >>>>>>>>> >> > >>>>>>>>> Would become: >> > >>>>>>>>> var myObj = { >> > >>>>>>>>> "name": "foo", >> > >>>>>>>>> "age" : 30 >> > >>>>>>>>> } >> > >>>>>>>>> >> > >>>>>>>>> These two features would have solved almost all minification >> > >>>>>>>>> issues >> > >>>>>>>>> I’ve >> > >>>>>>>>> run into. >> > >>>>>>>>> >> > >>>>>>>>> I’d love to work on this myself, but I’m still not up to >>making >> > >>>>>>>>> any >> > >>>>>>>>> major >> > >>>>>>>>> changes to the compiler… :-( >> > >>>>>>>>> >> > >>>>>>>>>> On Feb 5, 2018, at 6:13 PM, Alex Harui >> <[email protected]> >> > >>>>>>>>>> wrote: >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <[email protected]> >> wrote: >> > >>>>>>>>>> >> > >>>>>>>>>>> I’ll try to work on this. It’s pretty slow loading the >>debug >> > >>>>>>>>>>> build. >> > >>>>>>>>>>> >> > >>>>>>>>>>> I still maintain there should be a compiler setting or >> language >> > >>>>>>>>>>> feature >> > >>>>>>>>>>> to prevent objects produced from JSON being destroyed on >> > >>>>>>>>>>> minification. >> > >>>>>>>>>> >> > >>>>>>>>>> JSON Objects are not destroyed. The code referencing their >> > >>>>>>>>>> fields >> > >>>>>>>>>> by >> > >>>>>>>>>> name >> > >>>>>>>>>> has those names changed. Propose a way to determine that a >> data >> > >>>>>>>>>> structure >> > >>>>>>>>>> is external and what the compiler should generate and >> implement >> > >>>>>>>>>> it. >> > >>>>>>>>>> IMO, >> > >>>>>>>>>> the answer is to create ValueObjects. That is essentially >> > >>>>>>>>>> typedefs >> > >>>>>>>>>> and >> > >>>>>>>>>> AFAIK, there is no way to automate typedef generation. >> > >>>>>>>>>> >> > >>>>>>>>>> Also, you can turn off minification for the app as a whole. >> > >>>>>>>>>> >> > >>>>>>>>>> Other ideas welcome, >> > >>>>>>>>>> -Alex >> > >>>>>>>>>> >> > >>>>>>>>>>> This remains a pain point for developing apps and having >>to >> > >>>>>>>>>>> create >> > >>>>>>>>>>> VOs >> > >>>>>>>>>>> for every API is a drag. >> > >>>>>>>>>>> >> > >>>>>>>>>>>> On Feb 5, 2018, at 10:21 AM, Alex Harui >> > >>>>>>>>>>>> <[email protected]> >> > >>>>>>>>>>>> wrote: >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <[email protected]> >> wrote: >> > >>>>>>>>>>>> >> > >>>>>>>>>>>>> Typo. I meant js-reease. >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> Yeah, at some later point in time someone should build >>Value >> > >>>>>>>>>>>> Objects >> > >>>>>>>>>>>> for >> > >>>>>>>>>>>> the JSON and get js-release working. Maybe after this >> release. >> > >>>>>>>>>>>> I'm >> > >>>>>>>>>>>> just >> > >>>>>>>>>>>> trying to make the ASDoc useful. >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> I'm going to add Events to the class detail page and >>anchor >> > >>>>>>>>>>>> links >> > >>>>>>>>>>>> from >> > >>>>>>>>>>>> the >> > >>>>>>>>>>>> lists to the details and maybe a simple search-for-class >> > >>>>>>>>>>>> feature, >> > >>>>>>>>>>>> then I >> > >>>>>>>>>>>> think it will be time for a release. >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> -Alex >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>>>> On Feb 4, 2018, at 8:08 AM, Alex Harui >> > >>>>>>>>>>>>>> <[email protected]> >> > >>>>>>>>>>>>>> wrote: >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> 1. Why is bin-release not working? >> > >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> Do you mean SWF support? >> > >>>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>> >> > >>>>>>> >> > >>>>>> >> > >>>>> >> > >>>> >> > >>> >> > >> >> > > >> > >> > >> > > > >-- >Carlos Rovira >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C16f65e18ee564aa421b308d5 >6f22fef3%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636537118603984962&s >data=bFel9Zwl4bBQWQNBB0UqK5j36pUSXjph1yeExZQOwjw%3D&reserved=0
