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? >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
