royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabe Harbs <harbs.li...@gmail.com>
Subject Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)
Date Tue, 06 Feb 2018 10:59:59 GMT
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.lists@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 <aharui@adobe.com.INVALID <mailto:aharui@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.lists@gmail.com <mailto:harbs.lists@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.lists@gmail.com <mailto:harbs.lists@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 <aharui@adobe.com.INVALID <mailto:aharui@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.lists@gmail.com <mailto:harbs.lists@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 <aharui@adobe.com.INVALID
<mailto:aharui@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.lists@gmail.com <mailto:harbs.lists@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 <aharui@adobe.com.INVALID
<mailto:aharui@adobe.com.INVALID>>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.lists@gmail.com
<mailto:harbs.lists@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
>>>>>>>>>>> <aharui@adobe.com.INVALID <mailto:aharui@adobe.com.INVALID>>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <harbs.lists@gmail.com
<mailto:harbs.lists@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
>>>>>>>>>>>>> <aharui@adobe.com.INVALID <mailto:aharui@adobe.com.INVALID>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message