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 http://about.me/carlosrovira
