To illustrate that the VO solution is also error prone, I’m pretty sure that this page has a mistake: http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/RoyaleDocs_Staging/lastSuccessfulBuild/artifact/_site/create-an-application/application-tutorial/value-objects.html <http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/RoyaleDocs_Staging/lastSuccessfulBuild/artifact/_site/create-an-application/application-tutorial/value-objects.html>
Unless I’m missing something, the following line can be renamed: data.message = commitObj.message; I think it should have been: data.message = commitObj[“message”]; Harbs > On Feb 6, 2018, at 12:48 PM, Gabe Harbs <harbs.li...@gmail.com> wrote: > > 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 >> <mailto: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 >> <mailto: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 >>>> <mailto: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 >>>>> <mailto: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 >>>>> <mailto: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 >>>>>>> <mailto: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 >>>>>>> <mailto: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 >>>>>>>>> <mailto:aha...@adobe.com.INVALID>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.li...@gmail.com >>>>>>>>> <mailto: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 <mailto:aha...@adobe.com.INVALID>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <harbs.li...@gmail.com >>>>>>>>>>> <mailto: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 <mailto:aha...@adobe.com.INVALID>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Why is bin-release not working? >>>>>>>>>>>>> >>>>>>>>>>>>> Do you mean SWF support? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >