I’m really not sure how you plan on going about strongly typing hierarchical data.
> On Feb 6, 2018, at 7:13 PM, Gabe Harbs <[email protected]> wrote: > > What kind of utility do you have in mind? > > >> On Feb 6, 2018, at 7:09 PM, Alex Harui <[email protected]> wrote: >> >> Don't bother making VO's by hand for ASDoc. Let's write a utility to >> generate it. It will save everyone time. If you want to see >> bin/js-release, change the build to not use ADVANCED_OPTIMIZATIONS for now. >> >> There are lots of reasons to avoid using plain Object in a Royale app >> other than as a hash map. IMO, most C and Java apps don't use generic >> untyped dynamic bags of properties. If I add a warning about Object use, >> there will be a directive to suppress it. Objects are prone to error, and >> there is some indication that runtimes work better with type information. >> The JS runtimes wouldn't bother type inferencing otherwise. WASM hints >> that it wants types. >> >> My 2 cents, >> -Alex >> >> On 2/6/18, 8:45 AM, "Gabe Harbs" <[email protected]> wrote: >> >>> Huh? >>> >>> I don’t see how it’s possible to avoid Object completely. Even using VOs >>> require constructing them from Objects when coming from outside sources. >>> >>> Again: I’m not arguing against using VOs when possible/practical. I’m >>> just arguing that use of dot notation on Objects shouldn’t blow up your >>> app. >>> >>> Right now, I’m creating VOs for the ASDoc app. It’s kind of tedious work… >>> >>> Harbs >>> >>>> On Feb 6, 2018, at 6:40 PM, Alex Harui <[email protected]> wrote: >>>> >>>> Good catch. I fixed that. >>>> >>>> Actually, you are arguing in favor of ValueObjects. The error was there >>>> because commitObj was a plain Object so the compiler couldn't understand >>>> more about it. We want to not have any plain objects in a Royale app. >>>> They only create potential problems. In fact, maybe it is time for me >>>> to >>>> figure out how to generate warnings on every use of plain Object. >>>> Eventually we will have typedefs for the GitHub value objects and then >>>> there wouldn't be an issue like this. >>>> >>>> Thanks for proving my point. >>>> >>>> -Alex >>>> >>>> On 2/6/18, 2:59 AM, "Gabe Harbs" <[email protected]> wrote: >>>> >>>>> To illustrate that the VO solution is also error prone, I’m pretty sure >>>>> that this page has a mistake: >>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachero >>>>> ya >>>>> >>>>> leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flast >>>>> Su >>>>> >>>>> ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-t >>>>> ut >>>>> >>>>> orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e4 >>>>> 9b >>>>> >>>>> b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653 >>>>> 51 >>>>> >>>>> 16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&reser >>>>> ve >>>>> d=0 >>>>> >>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacher >>>>> oy >>>>> >>>>> aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flas >>>>> tS >>>>> >>>>> uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication- >>>>> tu >>>>> >>>>> torial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e >>>>> 49 >>>>> >>>>> bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365 >>>>> 35 >>>>> >>>>> 116172825365&sdata=3m3kTW910JYWV8MaM4%2F%2B3v82l5EvxIqgRjqAtIC7N%2BU%3D& >>>>> re >>>>> served=0> >>>>> >>>>> 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 <[email protected]> wrote: >>>>>> >>>>>> Related: >>>>>> >>>>>> On this page: >>>>>> >>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacher >>>>>> oy >>>>>> >>>>>> aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Fla >>>>>> st >>>>>> >>>>>> SuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicatio >>>>>> n- >>>>>> >>>>>> tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb44 >>>>>> 3d >>>>>> >>>>>> dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535116 >>>>>> 17 >>>>>> >>>>>> 2825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&re >>>>>> se >>>>>> rved=0 >>>>>> >>>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache >>>>>> ro >>>>>> >>>>>> yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Fl >>>>>> as >>>>>> >>>>>> tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicati >>>>>> on >>>>>> >>>>>> -tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb4 >>>>>> 43 >>>>>> >>>>>> ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511 >>>>>> 61 >>>>>> >>>>>> 72825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&r >>>>>> es >>>>>> erved=0> >>>>>> >>>>>> 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 <[email protected] >>>>>>> <mailto:[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] >>>>>>> <mailto:[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] >>>>>>>>> <mailto:[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] >>>>>>>>>> <mailto:[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] >>>>>>>>>> <mailto:[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] >>>>>>>>>>>> <mailto:[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] >>>>>>>>>>>> <mailto:[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] <mailto:[email protected]>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <[email protected] >>>>>>>>>>>>>> <mailto:[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] <mailto:[email protected]>> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <[email protected] >>>>>>>>>>>>>>>> <mailto:[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] >>>>>>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 1. Why is bin-release not working? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Do you mean SWF support? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
