but why to complicate this so much? I think we always had in Flex/Flash the opportunity to make this without any additional config. Why not left it as it always was?
thanks 2018-02-08 19:48 GMT+01:00 Alex Harui <[email protected]>: > 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 > > -- Carlos Rovira http://about.me/carlosrovira
