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 <[email protected]> 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 <[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?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
