Related: On this page: http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/RoyaleDocs_Staging/lastSuccessfulBuild/artifact/_site/create-an-application/application-tutorial/data.html <http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/RoyaleDocs_Staging/lastSuccessfulBuild/artifact/_site/create-an-application/application-tutorial/data.html>
Shouldn’t the following code have trouble with minification? { repos = configurator.json.repos; projectName = configurator.json.projectName; } What’s preventing json.repos and json.projectName from being renamed? > On Feb 5, 2018, at 11:34 PM, Alex Harui <aha...@adobe.com.INVALID> 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" <harbs.li...@gmail.com> 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 <harbs.li...@gmail.com> 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 <aha...@adobe.com.INVALID> >>>> 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" <harbs.li...@gmail.com> 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 <aha...@adobe.com.INVALID> >>>>>> 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" <harbs.li...@gmail.com> 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 <aha...@adobe.com.INVALID> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.li...@gmail.com> 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 >>>>>>>>>> <aha...@adobe.com.INVALID> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <harbs.li...@gmail.com> 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 >>>>>>>>>>>> <aha...@adobe.com.INVALID> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> 1. Why is bin-release not working? >>>>>>>>>>>> >>>>>>>>>>>> Do you mean SWF support? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >