JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Alex Harui <ah...@adobe.com.INVALID>]

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" <ha...@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID>
>>>>wrote:
>>>> 
>>>> 
>>>> 
>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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 <ah...@adobe.com.INVALID>
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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 <ah...@adobe.com.INVALID>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>> 
>>>>>>>> Do you mean SWF support?
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Piotr Zarzycki <pi...@gmail.com>]

I'm not sure how solution should look like, but in case of going by the
parse path I have raised some time ago jira [1]. Maybe it is a good place
to refresh that.

[1] https://issues.apache.org/jira/browse/FLEX-35297

Thanks,
Piotr

2018-02-06 10:14 GMT+01:00 Gabe Harbs <ha...@gmail.com>:

> I’m suggesting we have a compiler option to do it for all Object-typed
> properties. This problem is not limited to objects coming from JSON.
>
> The bracket access gets converted to dot access when google minifies the
> code, so there’s no effect on the minified code other than preventing the
> renaming.
>
> I’m all for making using value objects easier too.
>
> You lost me on the part about SOAP.
>
> Harbs
>
> > On Feb 6, 2018, at 11:05 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > I'm not convinced we can know when to generate obj.property vs
> > obj["property"] unless we do it for all Objects, not just ones that came
> > from JSON.  Or for all property access.  And that is at least 3 extra
> > characters per access for anything that isn't JSON.
> >
> > I would rather we find ways to make use of ValueObjects easier.  IMO,
> type
> > information will make development faster by catching errors sooner, and
> > has the potential to make the runtime performance faster, especially if
> we
> > consider other targets besides JS some day.
> >
> > To me, the problem is roughly the same as XML decoding into ValueObjects.
> > In XML/SOAP there was a WSDL and some utility converted it to AS
> > ValueObjects.  Other metadata instructed AMF to construct real classes
> > instead of plain objects.  I think there are APIs for that in JSON.parse.
> > I guess I will look into that for the next release.  IMO, if we can't
> > convince folks to use the type system, we lose a major productivity
> > advantage of Royale.  There is always going to be more setup work for
> > Royale. You can't just copy a file and view it in the browser.  You have
> > to run our compiler first.  We should encourage you to create
> ValueObjects
> > at some point.  My tutorial suggests doing it before creating a
> production
> > version.
> >
> > My 2 cents,
> > -Alex
> >
> > On 2/6/18, 12:51 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
> >
> >> Quite sure. In my angular app I was using an older version of the
> closure
> >> compiler to minify the js files. I was using the default options which
> >> clearly does not use ADVANCED_OPTIMIZATIONS, so the object literals
> >> didn’t get renamed.
> >>
> >> I think most modern app frameworks use other tools such as Babel for
> >> magnification, but I believe that handles object literals correctly too.
> >>
> >> We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
> >> object literals. I’m proposing a compiler *option* to allow to continue
> >> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
> >> should not be renamed.
> >>
> >> Harbs
> >>
> >>> On Feb 6, 2018, at 9:38 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>>
> >>> Are you sure Angular and React minify your code instead of running it
> >>> against their minified framework?
> >>>
> >>> -Alex
> >>>
> >>> On 2/5/18, 11:22 PM, "Gabe Harbs" <ha...@gmail.com> 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.
> >>>>
> >>>> It does.
> >>>>
> >>>> I’ve written angular apps and I’ve never had to worry about using
> >>>> bracket
> >>>> notation for minifying simple js objects. I’m pretty sure the same is
> >>>> for
> >>>> React, etc.
> >>>>
> >>>>> On Feb 5, 2018, at 11:34 PM, Alex Harui <ah...@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" <ha...@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 <ha...@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 <ah...@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" <ha...@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
> >
> >>>>>>>>>> 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" <ha...@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
> >>>>>>>>>>>> <ah...@adobe.com.INVALID>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
> >>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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
> >>>>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 1. Why is bin-release not working?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Do you mean SWF support?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Gabe Harbs <ha...@gmail.com>]

I’m suggesting we have a compiler option to do it for all Object-typed properties. This problem is not limited to objects coming from JSON.

The bracket access gets converted to dot access when google minifies the code, so there’s no effect on the minified code other than preventing the renaming.

I’m all for making using value objects easier too.

You lost me on the part about SOAP.

Harbs

> On Feb 6, 2018, at 11:05 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
> 
> I'm not convinced we can know when to generate obj.property vs
> obj["property"] unless we do it for all Objects, not just ones that came
> from JSON.  Or for all property access.  And that is at least 3 extra
> characters per access for anything that isn't JSON.
> 
> I would rather we find ways to make use of ValueObjects easier.  IMO, type
> information will make development faster by catching errors sooner, and
> has the potential to make the runtime performance faster, especially if we
> consider other targets besides JS some day.
> 
> To me, the problem is roughly the same as XML decoding into ValueObjects.
> In XML/SOAP there was a WSDL and some utility converted it to AS
> ValueObjects.  Other metadata instructed AMF to construct real classes
> instead of plain objects.  I think there are APIs for that in JSON.parse.
> I guess I will look into that for the next release.  IMO, if we can't
> convince folks to use the type system, we lose a major productivity
> advantage of Royale.  There is always going to be more setup work for
> Royale. You can't just copy a file and view it in the browser.  You have
> to run our compiler first.  We should encourage you to create ValueObjects
> at some point.  My tutorial suggests doing it before creating a production
> version.
> 
> My 2 cents,
> -Alex
> 
> On 2/6/18, 12:51 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
> 
>> Quite sure. In my angular app I was using an older version of the closure
>> compiler to minify the js files. I was using the default options which
>> clearly does not use ADVANCED_OPTIMIZATIONS, so the object literals
>> didn’t get renamed.
>> 
>> I think most modern app frameworks use other tools such as Babel for
>> magnification, but I believe that handles object literals correctly too.
>> 
>> We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
>> object literals. I’m proposing a compiler *option* to allow to continue
>> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
>> should not be renamed.
>> 
>> Harbs
>> 
>>> On Feb 6, 2018, at 9:38 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>> 
>>> Are you sure Angular and React minify your code instead of running it
>>> against their minified framework?
>>> 
>>> -Alex
>>> 
>>> On 2/5/18, 11:22 PM, "Gabe Harbs" <ha...@gmail.com> 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.
>>>> 
>>>> It does.
>>>> 
>>>> I’ve written angular apps and I’ve never had to worry about using
>>>> bracket
>>>> notation for minifying simple js objects. I’m pretty sure the same is
>>>> for
>>>> React, etc.
>>>> 
>>>>> On Feb 5, 2018, at 11:34 PM, Alex Harui <ah...@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" <ha...@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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Alex Harui <ah...@adobe.com.INVALID>]

I'm not convinced we can know when to generate obj.property vs
obj["property"] unless we do it for all Objects, not just ones that came
from JSON.  Or for all property access.  And that is at least 3 extra
characters per access for anything that isn't JSON.

I would rather we find ways to make use of ValueObjects easier.  IMO, type
information will make development faster by catching errors sooner, and
has the potential to make the runtime performance faster, especially if we
consider other targets besides JS some day.

To me, the problem is roughly the same as XML decoding into ValueObjects.
In XML/SOAP there was a WSDL and some utility converted it to AS
ValueObjects.  Other metadata instructed AMF to construct real classes
instead of plain objects.  I think there are APIs for that in JSON.parse.
I guess I will look into that for the next release.  IMO, if we can't
convince folks to use the type system, we lose a major productivity
advantage of Royale.  There is always going to be more setup work for
Royale. You can't just copy a file and view it in the browser.  You have
to run our compiler first.  We should encourage you to create ValueObjects
at some point.  My tutorial suggests doing it before creating a production
version.

My 2 cents,
-Alex

On 2/6/18, 12:51 AM, "Gabe Harbs" <ha...@gmail.com> wrote:

>Quite sure. In my angular app I was using an older version of the closure
>compiler to minify the js files. I was using the default options which
>clearly does not use ADVANCED_OPTIMIZATIONS, so the object literals
>didn’t get renamed.
>
>I think most modern app frameworks use other tools such as Babel for
>magnification, but I believe that handles object literals correctly too.
>
>We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
>object literals. I’m proposing a compiler *option* to allow to continue
>using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
>should not be renamed.
>
>Harbs
>
>> On Feb 6, 2018, at 9:38 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>> 
>> Are you sure Angular and React minify your code instead of running it
>> against their minified framework?
>> 
>> -Alex
>> 
>> On 2/5/18, 11:22 PM, "Gabe Harbs" <ha...@gmail.com> 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.
>>> 
>>> It does.
>>> 
>>> I’ve written angular apps and I’ve never had to worry about using
>>>bracket
>>> notation for minifying simple js objects. I’m pretty sure the same is
>>>for
>>> React, etc.
>>> 
>>>> On Feb 5, 2018, at 11:34 PM, Alex Harui <ah...@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" <ha...@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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>>>>>>>><ah...@adobe.com.INVALID>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Dave Fisher <da...@comcast.net>]

Sent from my iPhone

> On Feb 8, 2018, at 2:10 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
> 
> We can "leave it as it was" by making SIMPLE_OPTIMIZATIONS the default.
> The difference between Flex and Royale is that Royale currently crunches
> your code through the Google Closure Compiler with ADVANCED_OPTIMIZATIONS
> and that messes up how you use plain objects.
> 
> IMO, there is enough to gain from using ValueObjects (code hinting,
> type-checking, etc) that we should promote use of them and make it really
> easy to use them, like creating typedefs via some utility.  IOW, if it
> only took 5 minutes to generate ValueObjects for your JSON responses,
> would you just use them because it saved you time making mistakes using
> plain object?
> 
> But if enough folks want to use plain objects in production (this is not
> an issue for the bin/js-debug version) I have no objection to making it
> work, I'm just wondering if we should just use SIMPLE_OPTIMIZATIONS since
> that is easy, or take the time to add another compiler option and fork the
> output code generators to generate different code (and write tests for all
> of that).  Would ADVANCED_OPTIMIZATIONS plus this new option be worth it
> over SIMPLE_OPTIMIZATIONS?
> 
> If we change our default to SIMPLE_OPTIMIZATIONS our HelloWorld will be
> fatter, but I don't know by how much.  But that is a consideration if
> folks are going to care about download size.

A comparison would help. I don’t know what scale you have in mind. 

FWIW - If someone hosting a Royale app truly cares then there are additional outside the scope of Royale solutions like gzip and PageSpeed.

Regards,
Dave

> 
> Thoughts?
> -Alex
> 
> On 2/8/18, 1:55 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
> 
>> but why to complicate this so much? I think we always had in Flex/Flash
>> the
>> opportunity to make this without any additional config.
>> Why not left it as it always was?
>> 
>> thanks
>> 
>> 2018-02-08 19:48 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>> 
>>> I'm not disagreeing. I think the question is whether we need yet another
>>> compiler option to generate bracket notation for objects or just ask
>>> folks
>>> to use SIMPLE_OPTIMIZATIONS.  And whether we switch to
>>> SIMPLE_OPTIMIZATIONS by default.  I can think of lots of other things to
>>> work on besides this new option if we have rough equivalents.
>>> 
>>> -Alex
>>> 
>>> On 2/8/18, 10:36 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>> Rovira"
>>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>> 
>>>> Although I'm pro typed,  I agree with Josh that we should not enforce
>>>> that.
>>>> That's one of the great points in Flash/Flex.
>>>> For make things quick, I use simple objects with bracket notation, when
>>>> the
>>>> application is more relevant I go the right typed path.
>>>> It's up to the developer decide when they want one or another.
>>>> 
>>>> 
>>>> 
>>>> 2018-02-08 18:50 GMT+01:00 Josh Tynjala <jo...@apache.org>:
>>>> 
>>>>> Nothing frustrated me more about Royale/FlexJS than the fact that I
>>>>> couldn't use untyped objects without bracket notation. It's a very
>>> bad
>>>>> user
>>>>> experience when trying to consume JSON, or even when choosing to
>>> create
>>>>> my
>>>>> own object literals. While it's a good best practice to create value
>>>>> objects, that shouldn't be forced on everyone. I frequently use
>>> untyped
>>>>> objects when prototyping because it's more convenient. They're also
>>>>> useful
>>>>> in example code to reduce boilerplate that isn't particularly
>>> relevant
>>>>> to
>>>>> the concept/feature that you're trying to demonstrate. And, of
>>> course,
>>>>> there's the already mentioned JSON.
>>>>> 
>>>>> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS
>>> the
>>>>> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
>>>>> larger file size is an acceptable trade off, if it reduces the
>>>>> frustration
>>>>> of this situation. Especially for new users who will absolutely think
>>>>> its a
>>>>> serious bug in the Royale compiler. However, as Harbs notes here, if
>>> the
>>>>> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be
>>>>> retained.
>>>>> The compiler could generate code differently when something resolves
>>> as
>>>>> the
>>>>> Object type. The emitter could translate dot notation normally most
>>> of
>>>>> the
>>>>> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
>>>>> detects Object, switch to bracket notation instead. I believe it
>>> would
>>>>> also
>>>>> need to add quotes around properties defined in object literals.
>>>>> 
>>>>> Ideally, the following code should work properly out of the box:
>>>>> 
>>>>> var obj:Object = {one: 1, "two": 2};
>>>>> obj.three = 3;
>>>>> obj["four"] = 4;
>>>>> var one:Number = obj["one"];
>>>>> var two:Number = obj.two;
>>>>> var three:Number = obj["three"];
>>>>> var four:Number = obj.four;
>>>>> 
>>>>> The compiler would probably emit something like this to make it work
>>>>> with
>>>>> the Closure compiler's ADVANCED_OPTIMIZATIONS:
>>>>> 
>>>>> var obj:Object = {"one": 1, "two": 2};
>>>>> obj["three"] = 3;
>>>>> obj["four"] = 4;
>>>>> var one:Number = obj["one"];
>>>>> var two:Number = obj["two"];
>>>>> var three:Number = obj["three"];
>>>>> var four:Number = obj["four"];
>>>>> 
>>>>> Again, that's only for when something is typed as Object. If
>>> something
>>>>> actually has a class, let Closure compiler go nuts and rename
>>>>> everything it
>>>>> wants.
>>>>> 
>>>>> - Josh
>>>>> 
>>>>>> On 2018/02/06 08:51:19, Gabe Harbs <ha...@gmail.com> wrote:
>>>>>> Quite sure. In my angular app I was using an older version of the
>>>>> closure compiler to minify the js files. I was using the default
>>> options
>>>>> which clearly does not use ADVANCED_OPTIMIZATIONS, so the object
>>>>> literals
>>>>> didn’t get renamed.
>>>>>> 
>>>>>> I think most modern app frameworks use other tools such as Babel
>>> for
>>>>> magnification, but I believe that handles object literals correctly
>>> too.
>>>>>> 
>>>>>> We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s
>>> killing
>>>>> object literals. I’m proposing a compiler *option* to allow to
>>> continue
>>>>> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
>>>>> should
>>>>> not be renamed.
>>>>>> 
>>>>>> Harbs
>>>>>> 
>>>>>>> On Feb 6, 2018, at 9:38 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>>> wrote:
>>>>>>> 
>>>>>>> Are you sure Angular and React minify your code instead of
>>> running
>>>>> it
>>>>>>> against their minified framework?
>>>>>>> 
>>>>>>> -Alex
>>>>>>> 
>>>>>>> On 2/5/18, 11:22 PM, "Gabe Harbs" <ha...@gmail.com> 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.
>>>>>>>> 
>>>>>>>> It does.
>>>>>>>> 
>>>>>>>> I’ve written angular apps and I’ve never had to worry about
>>> using
>>>>> bracket
>>>>>>>> notation for minifying simple js objects. I’m pretty sure the
>>> same
>>>>> is
>>>>> for
>>>>>>>> React, etc.
>>>>>>>> 
>>>>>>>>> On Feb 5, 2018, at 11:34 PM, Alex Harui
>>> <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" <ha...@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
>>> <ha...@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
>>>>> <ah...@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" <ha...@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
>>>>>> 
>>>>>>>>>>>>>> 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" <ha...@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
>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs"
>>> <ha...@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
>>>>>>>>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Carlos Rovira
>>>> https://na01.safelinks.protection.outlook.com/?url=
>>> http%3A%2F%2Fabout.me%2
>>>> Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
>>> 7C16f65e18ee564aa421b308d5
>>>> 6f22fef3%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
>>> 7C636537118603984962&s
>>>> data=bFel9Zwl4bBQWQNBB0UqK5j36pUSXjph1yeExZQOwjw%3D&reserved=0
>>> 
>>> 
>> 
>> 
>> -- 
>> Carlos Rovira
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>> Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2fde110ce8564489482608d5
>> 6f3ebb3a%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636537237863888227&s
>> data=NzRRhywOm8%2FOHplSf0Q3f6dHLc480KaWNxYLScrFpRQ%3D&reserved=0
> 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Alex Harui <ah...@adobe.com.INVALID>]

We can "leave it as it was" by making SIMPLE_OPTIMIZATIONS the default.
The difference between Flex and Royale is that Royale currently crunches
your code through the Google Closure Compiler with ADVANCED_OPTIMIZATIONS
and that messes up how you use plain objects.

IMO, there is enough to gain from using ValueObjects (code hinting,
type-checking, etc) that we should promote use of them and make it really
easy to use them, like creating typedefs via some utility.  IOW, if it
only took 5 minutes to generate ValueObjects for your JSON responses,
would you just use them because it saved you time making mistakes using
plain object?

But if enough folks want to use plain objects in production (this is not
an issue for the bin/js-debug version) I have no objection to making it
work, I'm just wondering if we should just use SIMPLE_OPTIMIZATIONS since
that is easy, or take the time to add another compiler option and fork the
output code generators to generate different code (and write tests for all
of that).  Would ADVANCED_OPTIMIZATIONS plus this new option be worth it
over SIMPLE_OPTIMIZATIONS?

If we change our default to SIMPLE_OPTIMIZATIONS our HelloWorld will be
fatter, but I don't know by how much.  But that is a consideration if
folks are going to care about download size.

Thoughts?
-Alex

On 2/8/18, 1:55 PM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:

>but why to complicate this so much? I think we always had in Flex/Flash
>the
>opportunity to make this without any additional config.
>Why not left it as it always was?
>
>thanks
>
>2018-02-08 19:48 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
>
>> I'm not disagreeing. I think the question is whether we need yet another
>> compiler option to generate bracket notation for objects or just ask
>>folks
>> to use SIMPLE_OPTIMIZATIONS.  And whether we switch to
>> SIMPLE_OPTIMIZATIONS by default.  I can think of lots of other things to
>> work on besides this new option if we have rough equivalents.
>>
>> -Alex
>>
>> On 2/8/18, 10:36 AM, "carlos.rovira@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>>
>> >Although I'm pro typed,  I agree with Josh that we should not enforce
>> >that.
>> >That's one of the great points in Flash/Flex.
>> >For make things quick, I use simple objects with bracket notation, when
>> >the
>> >application is more relevant I go the right typed path.
>> >It's up to the developer decide when they want one or another.
>> >
>> >
>> >
>> >2018-02-08 18:50 GMT+01:00 Josh Tynjala <jo...@apache.org>:
>> >
>> >> Nothing frustrated me more about Royale/FlexJS than the fact that I
>> >> couldn't use untyped objects without bracket notation. It's a very
>>bad
>> >>user
>> >> experience when trying to consume JSON, or even when choosing to
>>create
>> >>my
>> >> own object literals. While it's a good best practice to create value
>> >> objects, that shouldn't be forced on everyone. I frequently use
>>untyped
>> >> objects when prototyping because it's more convenient. They're also
>> >>useful
>> >> in example code to reduce boilerplate that isn't particularly
>>relevant
>> >>to
>> >> the concept/feature that you're trying to demonstrate. And, of
>>course,
>> >> there's the already mentioned JSON.
>> >>
>> >> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS
>>the
>> >> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
>> >> larger file size is an acceptable trade off, if it reduces the
>> >>frustration
>> >> of this situation. Especially for new users who will absolutely think
>> >>its a
>> >> serious bug in the Royale compiler. However, as Harbs notes here, if
>>the
>> >> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be
>> >>retained.
>> >> The compiler could generate code differently when something resolves
>>as
>> >>the
>> >> Object type. The emitter could translate dot notation normally most
>>of
>> >>the
>> >> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
>> >> detects Object, switch to bracket notation instead. I believe it
>>would
>> >>also
>> >> need to add quotes around properties defined in object literals.
>> >>
>> >> Ideally, the following code should work properly out of the box:
>> >>
>> >> var obj:Object = {one: 1, "two": 2};
>> >> obj.three = 3;
>> >> obj["four"] = 4;
>> >> var one:Number = obj["one"];
>> >> var two:Number = obj.two;
>> >> var three:Number = obj["three"];
>> >> var four:Number = obj.four;
>> >>
>> >> The compiler would probably emit something like this to make it work
>> >>with
>> >> the Closure compiler's ADVANCED_OPTIMIZATIONS:
>> >>
>> >> var obj:Object = {"one": 1, "two": 2};
>> >> obj["three"] = 3;
>> >> obj["four"] = 4;
>> >> var one:Number = obj["one"];
>> >> var two:Number = obj["two"];
>> >> var three:Number = obj["three"];
>> >> var four:Number = obj["four"];
>> >>
>> >> Again, that's only for when something is typed as Object. If
>>something
>> >> actually has a class, let Closure compiler go nuts and rename
>> >>everything it
>> >> wants.
>> >>
>> >> - Josh
>> >>
>> >> On 2018/02/06 08:51:19, Gabe Harbs <ha...@gmail.com> wrote:
>> >> > Quite sure. In my angular app I was using an older version of the
>> >> closure compiler to minify the js files. I was using the default
>>options
>> >> which clearly does not use ADVANCED_OPTIMIZATIONS, so the object
>> >>literals
>> >> didn’t get renamed.
>> >> >
>> >> > I think most modern app frameworks use other tools such as Babel
>>for
>> >> magnification, but I believe that handles object literals correctly
>>too.
>> >> >
>> >> > We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s
>>killing
>> >> object literals. I’m proposing a compiler *option* to allow to
>>continue
>> >> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
>> >>should
>> >> not be renamed.
>> >> >
>> >> > Harbs
>> >> >
>> >> > > On Feb 6, 2018, at 9:38 AM, Alex Harui <ah...@adobe.com.INVALID>
>> >> wrote:
>> >> > >
>> >> > > Are you sure Angular and React minify your code instead of
>>running
>> >>it
>> >> > > against their minified framework?
>> >> > >
>> >> > > -Alex
>> >> > >
>> >> > > On 2/5/18, 11:22 PM, "Gabe Harbs" <ha...@gmail.com> 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.
>> >> > >>
>> >> > >> It does.
>> >> > >>
>> >> > >> I’ve written angular apps and I’ve never had to worry about
>>using
>> >> bracket
>> >> > >> notation for minifying simple js objects. I’m pretty sure the
>>same
>> >>is
>> >> for
>> >> > >> React, etc.
>> >> > >>
>> >> > >>> On Feb 5, 2018, at 11:34 PM, Alex Harui
>><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" <ha...@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
>><ha...@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
>> >><ah...@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" <ha...@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
>> >> >
>> >> > >>>>>>>> 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" <ha...@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
>> >> <ah...@adobe.com.INVALID>
>> >> > >>>>>>>>>> wrote:
>> >> > >>>>>>>>>>
>> >> > >>>>>>>>>>
>> >> > >>>>>>>>>>
>> >> > >>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
>> >> > >>>>>>>>>>>> <ah...@adobe.com.INVALID>
>> >> > >>>>>>>>>>>> wrote:
>> >> > >>>>>>>>>>>>
>> >> > >>>>>>>>>>>>
>> >> > >>>>>>>>>>>>
>> >> > >>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs"
>><ha...@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
>> >> > >>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>> >> > >>>>>>>>>>>>>> wrote:
>> >> > >>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>>> 1. Why is bin-release not working?
>> >> > >>>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>>> Do you mean SWF support?
>> >> > >>>>>>>>>>>>>
>> >> > >>>>>>>>>>>>
>> >> > >>>>>>>>>>>
>> >> > >>>>>>>>>>
>> >> > >>>>>>>>>
>> >> > >>>>>>>>
>> >> > >>>>>>>
>> >> > >>>>>>
>> >> > >>>>>
>> >> > >>>>
>> >> > >>>
>> >> > >>
>> >> > >
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>> >--
>> >Carlos Rovira
>> >https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
>> 7C16f65e18ee564aa421b308d5
>> >6f22fef3%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
>> 7C636537118603984962&s
>> >data=bFel9Zwl4bBQWQNBB0UqK5j36pUSXjph1yeExZQOwjw%3D&reserved=0
>>
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C2fde110ce8564489482608d5
>6f3ebb3a%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636537237863888227&s
>data=NzRRhywOm8%2FOHplSf0Q3f6dHLc480KaWNxYLScrFpRQ%3D&reserved=0

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Carlos Rovira <ca...@apache.org>]

but why to complicate this so much? I think we always had in Flex/Flash the
opportunity to make this without any additional config.
Why not left it as it always was?

thanks

2018-02-08 19:48 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:

> I'm not disagreeing. I think the question is whether we need yet another
> compiler option to generate bracket notation for objects or just ask folks
> to use SIMPLE_OPTIMIZATIONS.  And whether we switch to
> SIMPLE_OPTIMIZATIONS by default.  I can think of lots of other things to
> work on besides this new option if we have rough equivalents.
>
> -Alex
>
> On 2/8/18, 10:36 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Although I'm pro typed,  I agree with Josh that we should not enforce
> >that.
> >That's one of the great points in Flash/Flex.
> >For make things quick, I use simple objects with bracket notation, when
> >the
> >application is more relevant I go the right typed path.
> >It's up to the developer decide when they want one or another.
> >
> >
> >
> >2018-02-08 18:50 GMT+01:00 Josh Tynjala <jo...@apache.org>:
> >
> >> Nothing frustrated me more about Royale/FlexJS than the fact that I
> >> couldn't use untyped objects without bracket notation. It's a very bad
> >>user
> >> experience when trying to consume JSON, or even when choosing to create
> >>my
> >> own object literals. While it's a good best practice to create value
> >> objects, that shouldn't be forced on everyone. I frequently use untyped
> >> objects when prototyping because it's more convenient. They're also
> >>useful
> >> in example code to reduce boilerplate that isn't particularly relevant
> >>to
> >> the concept/feature that you're trying to demonstrate. And, of course,
> >> there's the already mentioned JSON.
> >>
> >> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS the
> >> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
> >> larger file size is an acceptable trade off, if it reduces the
> >>frustration
> >> of this situation. Especially for new users who will absolutely think
> >>its a
> >> serious bug in the Royale compiler. However, as Harbs notes here, if the
> >> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be
> >>retained.
> >> The compiler could generate code differently when something resolves as
> >>the
> >> Object type. The emitter could translate dot notation normally most of
> >>the
> >> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
> >> detects Object, switch to bracket notation instead. I believe it would
> >>also
> >> need to add quotes around properties defined in object literals.
> >>
> >> Ideally, the following code should work properly out of the box:
> >>
> >> var obj:Object = {one: 1, "two": 2};
> >> obj.three = 3;
> >> obj["four"] = 4;
> >> var one:Number = obj["one"];
> >> var two:Number = obj.two;
> >> var three:Number = obj["three"];
> >> var four:Number = obj.four;
> >>
> >> The compiler would probably emit something like this to make it work
> >>with
> >> the Closure compiler's ADVANCED_OPTIMIZATIONS:
> >>
> >> var obj:Object = {"one": 1, "two": 2};
> >> obj["three"] = 3;
> >> obj["four"] = 4;
> >> var one:Number = obj["one"];
> >> var two:Number = obj["two"];
> >> var three:Number = obj["three"];
> >> var four:Number = obj["four"];
> >>
> >> Again, that's only for when something is typed as Object. If something
> >> actually has a class, let Closure compiler go nuts and rename
> >>everything it
> >> wants.
> >>
> >> - Josh
> >>
> >> On 2018/02/06 08:51:19, Gabe Harbs <ha...@gmail.com> wrote:
> >> > Quite sure. In my angular app I was using an older version of the
> >> closure compiler to minify the js files. I was using the default options
> >> which clearly does not use ADVANCED_OPTIMIZATIONS, so the object
> >>literals
> >> didn’t get renamed.
> >> >
> >> > I think most modern app frameworks use other tools such as Babel for
> >> magnification, but I believe that handles object literals correctly too.
> >> >
> >> > We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
> >> object literals. I’m proposing a compiler *option* to allow to continue
> >> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
> >>should
> >> not be renamed.
> >> >
> >> > Harbs
> >> >
> >> > > On Feb 6, 2018, at 9:38 AM, Alex Harui <ah...@adobe.com.INVALID>
> >> wrote:
> >> > >
> >> > > Are you sure Angular and React minify your code instead of running
> >>it
> >> > > against their minified framework?
> >> > >
> >> > > -Alex
> >> > >
> >> > > On 2/5/18, 11:22 PM, "Gabe Harbs" <ha...@gmail.com> 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.
> >> > >>
> >> > >> It does.
> >> > >>
> >> > >> I’ve written angular apps and I’ve never had to worry about using
> >> bracket
> >> > >> notation for minifying simple js objects. I’m pretty sure the same
> >>is
> >> for
> >> > >> React, etc.
> >> > >>
> >> > >>> On Feb 5, 2018, at 11:34 PM, Alex Harui <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" <ha...@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 <ha...@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
> >><ah...@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" <ha...@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
> >> >
> >> > >>>>>>>> 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" <ha...@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
> >> <ah...@adobe.com.INVALID>
> >> > >>>>>>>>>> wrote:
> >> > >>>>>>>>>>
> >> > >>>>>>>>>>
> >> > >>>>>>>>>>
> >> > >>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
> >> > >>>>>>>>>>>> <ah...@adobe.com.INVALID>
> >> > >>>>>>>>>>>> wrote:
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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
> >> > >>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
> >> > >>>>>>>>>>>>>> wrote:
> >> > >>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>> 1. Why is bin-release not working?
> >> > >>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>> Do you mean SWF support?
> >> > >>>>>>>>>>>>>
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>
> >> > >>>>>>>>>>
> >> > >>>>>>>>>
> >> > >>>>>>>>
> >> > >>>>>>>
> >> > >>>>>>
> >> > >>>>>
> >> > >>>>
> >> > >>>
> >> > >>
> >> > >
> >> >
> >> >
> >>
> >
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C16f65e18ee564aa421b308d5
> >6f22fef3%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C636537118603984962&s
> >data=bFel9Zwl4bBQWQNBB0UqK5j36pUSXjph1yeExZQOwjw%3D&reserved=0
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Alex Harui <ah...@adobe.com.INVALID>]

I'm not disagreeing. I think the question is whether we need yet another
compiler option to generate bracket notation for objects or just ask folks
to use SIMPLE_OPTIMIZATIONS.  And whether we switch to
SIMPLE_OPTIMIZATIONS by default.  I can think of lots of other things to
work on besides this new option if we have rough equivalents.

-Alex

On 2/8/18, 10:36 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:

>Although I'm pro typed,  I agree with Josh that we should not enforce
>that.
>That's one of the great points in Flash/Flex.
>For make things quick, I use simple objects with bracket notation, when
>the
>application is more relevant I go the right typed path.
>It's up to the developer decide when they want one or another.
>
>
>
>2018-02-08 18:50 GMT+01:00 Josh Tynjala <jo...@apache.org>:
>
>> Nothing frustrated me more about Royale/FlexJS than the fact that I
>> couldn't use untyped objects without bracket notation. It's a very bad
>>user
>> experience when trying to consume JSON, or even when choosing to create
>>my
>> own object literals. While it's a good best practice to create value
>> objects, that shouldn't be forced on everyone. I frequently use untyped
>> objects when prototyping because it's more convenient. They're also
>>useful
>> in example code to reduce boilerplate that isn't particularly relevant
>>to
>> the concept/feature that you're trying to demonstrate. And, of course,
>> there's the already mentioned JSON.
>>
>> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS the
>> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
>> larger file size is an acceptable trade off, if it reduces the
>>frustration
>> of this situation. Especially for new users who will absolutely think
>>its a
>> serious bug in the Royale compiler. However, as Harbs notes here, if the
>> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be
>>retained.
>> The compiler could generate code differently when something resolves as
>>the
>> Object type. The emitter could translate dot notation normally most of
>>the
>> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
>> detects Object, switch to bracket notation instead. I believe it would
>>also
>> need to add quotes around properties defined in object literals.
>>
>> Ideally, the following code should work properly out of the box:
>>
>> var obj:Object = {one: 1, "two": 2};
>> obj.three = 3;
>> obj["four"] = 4;
>> var one:Number = obj["one"];
>> var two:Number = obj.two;
>> var three:Number = obj["three"];
>> var four:Number = obj.four;
>>
>> The compiler would probably emit something like this to make it work
>>with
>> the Closure compiler's ADVANCED_OPTIMIZATIONS:
>>
>> var obj:Object = {"one": 1, "two": 2};
>> obj["three"] = 3;
>> obj["four"] = 4;
>> var one:Number = obj["one"];
>> var two:Number = obj["two"];
>> var three:Number = obj["three"];
>> var four:Number = obj["four"];
>>
>> Again, that's only for when something is typed as Object. If something
>> actually has a class, let Closure compiler go nuts and rename
>>everything it
>> wants.
>>
>> - Josh
>>
>> On 2018/02/06 08:51:19, Gabe Harbs <ha...@gmail.com> wrote:
>> > Quite sure. In my angular app I was using an older version of the
>> closure compiler to minify the js files. I was using the default options
>> which clearly does not use ADVANCED_OPTIMIZATIONS, so the object
>>literals
>> didn’t get renamed.
>> >
>> > I think most modern app frameworks use other tools such as Babel for
>> magnification, but I believe that handles object literals correctly too.
>> >
>> > We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
>> object literals. I’m proposing a compiler *option* to allow to continue
>> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
>>should
>> not be renamed.
>> >
>> > Harbs
>> >
>> > > On Feb 6, 2018, at 9:38 AM, Alex Harui <ah...@adobe.com.INVALID>
>> wrote:
>> > >
>> > > Are you sure Angular and React minify your code instead of running
>>it
>> > > against their minified framework?
>> > >
>> > > -Alex
>> > >
>> > > On 2/5/18, 11:22 PM, "Gabe Harbs" <ha...@gmail.com> 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.
>> > >>
>> > >> It does.
>> > >>
>> > >> I’ve written angular apps and I’ve never had to worry about using
>> bracket
>> > >> notation for minifying simple js objects. I’m pretty sure the same
>>is
>> for
>> > >> React, etc.
>> > >>
>> > >>> On Feb 5, 2018, at 11:34 PM, Alex Harui <ah...@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" <ha...@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 <ha...@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
>><ah...@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" <ha...@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
>> >
>> > >>>>>>>> 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" <ha...@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
>> <ah...@adobe.com.INVALID>
>> > >>>>>>>>>> wrote:
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
>> > >>>>>>>>>>>> <ah...@adobe.com.INVALID>
>> > >>>>>>>>>>>> wrote:
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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
>> > >>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>> > >>>>>>>>>>>>>> wrote:
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>>> 1. Why is bin-release not working?
>> > >>>>>>>>>>>>>>
>> > >>>>>>>>>>>>>> Do you mean SWF support?
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>
>> > >>>>>>
>> > >>>>>
>> > >>>>
>> > >>>
>> > >>
>> > >
>> >
>> >
>>
>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C16f65e18ee564aa421b308d5
>6f22fef3%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636537118603984962&s
>data=bFel9Zwl4bBQWQNBB0UqK5j36pUSXjph1yeExZQOwjw%3D&reserved=0

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Carlos Rovira <ca...@apache.org>]

Although I'm pro typed,  I agree with Josh that we should not enforce that.
That's one of the great points in Flash/Flex.
For make things quick, I use simple objects with bracket notation, when the
application is more relevant I go the right typed path.
It's up to the developer decide when they want one or another.



2018-02-08 18:50 GMT+01:00 Josh Tynjala <jo...@apache.org>:

> Nothing frustrated me more about Royale/FlexJS than the fact that I
> couldn't use untyped objects without bracket notation. It's a very bad user
> experience when trying to consume JSON, or even when choosing to create my
> own object literals. While it's a good best practice to create value
> objects, that shouldn't be forced on everyone. I frequently use untyped
> objects when prototyping because it's more convenient. They're also useful
> in example code to reduce boilerplate that isn't particularly relevant to
> the concept/feature that you're trying to demonstrate. And, of course,
> there's the already mentioned JSON.
>
> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS the
> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
> larger file size is an acceptable trade off, if it reduces the frustration
> of this situation. Especially for new users who will absolutely think its a
> serious bug in the Royale compiler. However, as Harbs notes here, if the
> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be retained.
> The compiler could generate code differently when something resolves as the
> Object type. The emitter could translate dot notation normally most of the
> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
> detects Object, switch to bracket notation instead. I believe it would also
> need to add quotes around properties defined in object literals.
>
> Ideally, the following code should work properly out of the box:
>
> var obj:Object = {one: 1, "two": 2};
> obj.three = 3;
> obj["four"] = 4;
> var one:Number = obj["one"];
> var two:Number = obj.two;
> var three:Number = obj["three"];
> var four:Number = obj.four;
>
> The compiler would probably emit something like this to make it work with
> the Closure compiler's ADVANCED_OPTIMIZATIONS:
>
> var obj:Object = {"one": 1, "two": 2};
> obj["three"] = 3;
> obj["four"] = 4;
> var one:Number = obj["one"];
> var two:Number = obj["two"];
> var three:Number = obj["three"];
> var four:Number = obj["four"];
>
> Again, that's only for when something is typed as Object. If something
> actually has a class, let Closure compiler go nuts and rename everything it
> wants.
>
> - Josh
>
> On 2018/02/06 08:51:19, Gabe Harbs <ha...@gmail.com> wrote:
> > Quite sure. In my angular app I was using an older version of the
> closure compiler to minify the js files. I was using the default options
> which clearly does not use ADVANCED_OPTIMIZATIONS, so the object literals
> didn’t get renamed.
> >
> > I think most modern app frameworks use other tools such as Babel for
> magnification, but I believe that handles object literals correctly too.
> >
> > We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
> object literals. I’m proposing a compiler *option* to allow to continue
> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which should
> not be renamed.
> >
> > Harbs
> >
> > > On Feb 6, 2018, at 9:38 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> > >
> > > Are you sure Angular and React minify your code instead of running it
> > > against their minified framework?
> > >
> > > -Alex
> > >
> > > On 2/5/18, 11:22 PM, "Gabe Harbs" <ha...@gmail.com> 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.
> > >>
> > >> It does.
> > >>
> > >> I’ve written angular apps and I’ve never had to worry about using
> bracket
> > >> notation for minifying simple js objects. I’m pretty sure the same is
> for
> > >> React, etc.
> > >>
> > >>> On Feb 5, 2018, at 11:34 PM, Alex Harui <ah...@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" <ha...@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 <ha...@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 <ah...@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" <ha...@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
> >
> > >>>>>>>> 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" <ha...@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
> <ah...@adobe.com.INVALID>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
> > >>>>>>>>>>>> <ah...@adobe.com.INVALID>
> > >>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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
> > >>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 1. Why is bin-release not working?
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Do you mean SWF support?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> >
> >
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Josh Tynjala <jo...@apache.org>]

Nothing frustrated me more about Royale/FlexJS than the fact that I couldn't use untyped objects without bracket notation. It's a very bad user experience when trying to consume JSON, or even when choosing to create my own object literals. While it's a good best practice to create value objects, that shouldn't be forced on everyone. I frequently use untyped objects when prototyping because it's more convenient. They're also useful in example code to reduce boilerplate that isn't particularly relevant to the concept/feature that you're trying to demonstrate. And, of course, there's the already mentioned JSON.

In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS the default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly larger file size is an acceptable trade off, if it reduces the frustration of this situation. Especially for new users who will absolutely think its a serious bug in the Royale compiler. However, as Harbs notes here, if the compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be retained. The compiler could generate code differently when something resolves as the Object type. The emitter could translate dot notation normally most of the time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it detects Object, switch to bracket notation instead. I believe it would also need to add quotes around properties defined in object literals.

Ideally, the following code should work properly out of the box:

var obj:Object = {one: 1, "two": 2};
obj.three = 3;
obj["four"] = 4;
var one:Number = obj["one"];
var two:Number = obj.two;
var three:Number = obj["three"];
var four:Number = obj.four;

The compiler would probably emit something like this to make it work with the Closure compiler's ADVANCED_OPTIMIZATIONS:

var obj:Object = {"one": 1, "two": 2};
obj["three"] = 3;
obj["four"] = 4;
var one:Number = obj["one"];
var two:Number = obj["two"];
var three:Number = obj["three"];
var four:Number = obj["four"];

Again, that's only for when something is typed as Object. If something actually has a class, let Closure compiler go nuts and rename everything it wants.

- Josh

On 2018/02/06 08:51:19, Gabe Harbs <ha...@gmail.com> wrote: 
> Quite sure. In my angular app I was using an older version of the closure compiler to minify the js files. I was using the default options which clearly does not use ADVANCED_OPTIMIZATIONS, so the object literals didn’t get renamed.
> 
> I think most modern app frameworks use other tools such as Babel for magnification, but I believe that handles object literals correctly too.
> 
> We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing object literals. I’m proposing a compiler *option* to allow to continue using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which should not be renamed.
> 
> Harbs
> 
> > On Feb 6, 2018, at 9:38 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
> > 
> > Are you sure Angular and React minify your code instead of running it
> > against their minified framework?
> > 
> > -Alex
> > 
> > On 2/5/18, 11:22 PM, "Gabe Harbs" <ha...@gmail.com> 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.
> >> 
> >> It does.
> >> 
> >> I’ve written angular apps and I’ve never had to worry about using bracket
> >> notation for minifying simple js objects. I’m pretty sure the same is for
> >> React, etc.
> >> 
> >>> On Feb 5, 2018, at 11:34 PM, Alex Harui <ah...@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" <ha...@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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID>
> >>>>>>>>>> wrote:
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
> >>>>>>>>>>>> <ah...@adobe.com.INVALID>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>> 
> >>>>>>>>>>>> 
> >>>>>>>>>>>> 
> >>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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
> >>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>> 1. Why is bin-release not working?
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> Do you mean SWF support?
> >>>>>>>>>>>>> 
> >>>>>>>>>>>> 
> >>>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>> 
> >>>>>>> 
> >>>>>> 
> >>>>> 
> >>>> 
> >>> 
> >> 
> > 
> 
> 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Gabe Harbs <ha...@gmail.com>]

Quite sure. In my angular app I was using an older version of the closure compiler to minify the js files. I was using the default options which clearly does not use ADVANCED_OPTIMIZATIONS, so the object literals didn’t get renamed.

I think most modern app frameworks use other tools such as Babel for magnification, but I believe that handles object literals correctly too.

We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing object literals. I’m proposing a compiler *option* to allow to continue using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which should not be renamed.

Harbs

> On Feb 6, 2018, at 9:38 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
> 
> Are you sure Angular and React minify your code instead of running it
> against their minified framework?
> 
> -Alex
> 
> On 2/5/18, 11:22 PM, "Gabe Harbs" <ha...@gmail.com> 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.
>> 
>> It does.
>> 
>> I’ve written angular apps and I’ve never had to worry about using bracket
>> notation for minifying simple js objects. I’m pretty sure the same is for
>> React, etc.
>> 
>>> On Feb 5, 2018, at 11:34 PM, Alex Harui <ah...@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" <ha...@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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Alex Harui <ah...@adobe.com.INVALID>]

Are you sure Angular and React minify your code instead of running it
against their minified framework?

-Alex

On 2/5/18, 11:22 PM, "Gabe Harbs" <ha...@gmail.com> 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.
>
>It does.
>
>I’ve written angular apps and I’ve never had to worry about using bracket
>notation for minifying simple js objects. I’m pretty sure the same is for
>React, etc.
>
>> On Feb 5, 2018, at 11:34 PM, Alex Harui <ah...@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" <ha...@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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Gabe Harbs <ha...@gmail.com>]

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

It does.

I’ve written angular apps and I’ve never had to worry about using bracket notation for minifying simple js objects. I’m pretty sure the same is for React, etc.

> On Feb 5, 2018, at 11:34 PM, Alex Harui <ah...@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" <ha...@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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>> 
>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[OmPrakash Muppirala <bi...@gmail.com>]

The java Jackson parser supports metadata based specification that can tell
the deserializer to use a custom parser for specific sub properties.

https://fasterxml.github.io/jackson-annotations/javadoc/2.0.0/com/fasterxml/jackson/annotation/JsonSetter.html

This site has a pretty good rundown on Jackson
http://www.baeldung.com/jackson-annotations

Look for @jsonsetter.

Thanks
Om

On Feb 6, 2018 9:16 AM, "Gabe Harbs" <ha...@gmail.com> wrote:

> 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 <ha...@gmail.com> wrote:
> >
> > What kind of utility do you have in mind?
> >
> >
> >> On Feb 6, 2018, at 7:09 PM, Alex Harui <ah...@adobe.com.INVALID>
> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
> 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" <ha...@gmail.com> 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%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%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%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%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 <ha...@gmail.com>
> 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%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C636535116
> >>>>>> 17
> >>>>>>
> >>>>>> 2825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5s
> o%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%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C63653511
> >>>>>> 61
> >>>>>>
> >>>>>> 72825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5s
> o%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 <aharui@adobe.com.INVALID
> >>>>>>> <ma...@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
> >>>>>>> <ma...@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
> >>>>>>>>> <ma...@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
> >>>>>>>>>> <ma...@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
> >>>>>>>>>> <ma...@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
> >>>>>>>>>>>> <ma...@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
> >>>>>>>>>>>> <ma...@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
> >>>>>>>>>>>>>> <ma...@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
> >>>>>>>>>>>>>>>> <ma...@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
> >>>>>>>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 1. Why is bin-release not working?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Do you mean SWF support?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Alex Harui <ah...@adobe.com.INVALID>]

I'm going to work on this utility to generate AS classes from a JSON
result today unless someone is already working on it.

-Alex

On 2/7/18, 11:13 AM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:

>Two more thoughts on this utility.  I think you create a UID for each
>child class.  I think the UID can consist of the sorted property values
>and their types so for the snippet below the UID would be:
>
>  
>"baseClassname:String;description:String;members:Array;qname:String;tags:A
>r
>ray;type:String;"
>
>Then before creating a new child class, you first build the UID and see if
>already exists.  That way you can handle an Employee class being used in
>two different fields of a Company object.
>
>Also, you build out a cache of instances so you don't loop for references
>back to parent objects.
>
>If anyone gets started on the utility, let us know so we don't have more
>than one person working on it.
>
>Thanks,
>-Alex
>
>On 2/6/18, 9:53 AM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
>
>>Pretty sure something like this was done for Flash Builder.  You could
>>direct FB to generate ValueObjects from a WSDL.
>>
>>I'm imagining an AIR app that lets you specify a path to an output folder
>>and a class name and lets you paste a JSON result.
>>
>>If you look at the ASDoc structure for DataGrid.json, it looks like this:
>>
>>{ "type": "class",
>>  "qname": "org.apache.royale.express.DataGrid",
>>  "baseClassname": "org.apache.royale.html.DataGrid",
>>  "description": "This class extends DataGrid and adds beads for drag and
>>drop and column reordering.",
>>  "tags": [
>>     {  "tagName": "flexdocurl",
>>        "values":
>>["https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflex.a
>>p
>>ache.org%2Fasdoc%2Fspark%2Fcomponents%2FDataGrid.html&data=02%7C01%7Cahar
>>u
>>i%40adobe.com%7C364fbca7fc9144384fd808d56d8a96c0%7C71f1da39c0a84d5a8d88a6
>>7
>>b23c30bf4%7C0%7C0%7C636535364360288547&sdata=5%2FZyPUsg30zGUdqwPxr3XFu6Qi
>>o
>>FFL3%2BZ1RBl5kDADw%3D&reserved=0"]},
>>     {  "tagName": "flexcomponent",
>>        "values": ["spark.components.DataGrid"]}],
>>  "members": [
>>     { "type": "method",
>>       "qname": "org.apache.royale.express.DataGrid",
>>       "namespace": "",
>>       "return": "",
>>       "params": []},
>>     { "type": "method",
>>       "qname": "addedToParent",
>>       "namespace": "public",
>>       "override": true,
>>       "return": "void",
>>       "params": []}]
>>}
>>
>>So, I might call this "ClassData".  The utility would JSON.parse the
>>structure and walk each property.  If it sees the value is a String then
>>it sets the property type to String, if a number, then Number or int if
>>the value doesn't have decimal places.  True and false are Booleans.
>>Array for Arrays.
>>
>>If the value is an Array, it looks at the first element in the Array.  IF
>>the first element Is an Object, like it is for tags, it would create the
>>class ClassData_tags and walk the object.  Same for any value of a field
>>that is an Object.
>>
>>IMO, it doesn't have to be perfect, just save you most of the tedious
>>work.  And if you don't like the generated class names, the IDEs should
>>support refactoring (now or eventually).
>>
>>Of course, I could be wrong...
>>
>>-Alex
>>
>>
>>
>>On 2/6/18, 9:16 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>>
>>>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 <ha...@gmail.com> wrote:
>>>> 
>>>> What kind of utility do you have in mind?
>>>> 
>>>> 
>>>>> On Feb 6, 2018, at 7:09 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>>>>>>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" <ha...@gmail.com> 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%2Fapa
>>>>>>>>c
>>>>>>>>h
>>>>>>>>ero
>>>>>>>> ya
>>>>>>>> 
>>>>>>>> 
>>>>>>>>leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2
>>>>>>>>F
>>>>>>>>l
>>>>>>>>ast
>>>>>>>> Su
>>>>>>>> 
>>>>>>>> 
>>>>>>>>ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicat
>>>>>>>>i
>>>>>>>>o
>>>>>>>>n-t
>>>>>>>> ut
>>>>>>>> 
>>>>>>>> 
>>>>>>>>orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b
>>>>>>>>2
>>>>>>>>2
>>>>>>>>9e4
>>>>>>>> 9b
>>>>>>>> 
>>>>>>>> 
>>>>>>>>b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C
>>>>>>>>6
>>>>>>>>3
>>>>>>>>653
>>>>>>>> 51
>>>>>>>> 
>>>>>>>> 
>>>>>>>>16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&
>>>>>>>>r
>>>>>>>>e
>>>>>>>>ser
>>>>>>>> ve
>>>>>>>> d=0 
>>>>>>>> 
>>>>>>>> 
>>>>>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fap
>>>>>>>>a
>>>>>>>>c
>>>>>>>>her
>>>>>>>> oy
>>>>>>>> 
>>>>>>>> 
>>>>>>>>aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%
>>>>>>>>2
>>>>>>>>F
>>>>>>>>las
>>>>>>>> tS
>>>>>>>> 
>>>>>>>> 
>>>>>>>>uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplica
>>>>>>>>t
>>>>>>>>i
>>>>>>>>on-
>>>>>>>> tu
>>>>>>>> 
>>>>>>>> 
>>>>>>>>torial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924
>>>>>>>>b
>>>>>>>>2
>>>>>>>>29e
>>>>>>>> 49
>>>>>>>> 
>>>>>>>> 
>>>>>>>>bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7
>>>>>>>>C
>>>>>>>>6
>>>>>>>>365
>>>>>>>> 35
>>>>>>>> 
>>>>>>>> 
>>>>>>>>116172825365&sdata=3m3kTW910JYWV8MaM4%2F%2B3v82l5EvxIqgRjqAtIC7N%2B
>>>>>>>>U
>>>>>>>>%
>>>>>>>>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 <ha...@gmail.com>
>>>>>>>>>wrote:
>>>>>>>>> 
>>>>>>>>> Related:
>>>>>>>>> 
>>>>>>>>> On this page:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fap
>>>>>>>>>a
>>>>>>>>>c
>>>>>>>>>her
>>>>>>>>> oy
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging
>>>>>>>>>%
>>>>>>>>>2
>>>>>>>>>Fla
>>>>>>>>> st
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>SuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fappli
>>>>>>>>>c
>>>>>>>>>a
>>>>>>>>>tio
>>>>>>>>> n-
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e4
>>>>>>>>>9
>>>>>>>>>b
>>>>>>>>>b44
>>>>>>>>> 3d
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365
>>>>>>>>>3
>>>>>>>>>5
>>>>>>>>>116
>>>>>>>>> 17
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>2825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%
>>>>>>>>>3
>>>>>>>>>D
>>>>>>>>>&re
>>>>>>>>> se
>>>>>>>>> rved=0 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fa
>>>>>>>>>p
>>>>>>>>>a
>>>>>>>>>che
>>>>>>>>> ro
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Stagin
>>>>>>>>>g
>>>>>>>>>%
>>>>>>>>>2Fl
>>>>>>>>> as
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fappl
>>>>>>>>>i
>>>>>>>>>c
>>>>>>>>>ati
>>>>>>>>> on
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>-tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e
>>>>>>>>>4
>>>>>>>>>9
>>>>>>>>>bb4
>>>>>>>>> 43
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636
>>>>>>>>>5
>>>>>>>>>3
>>>>>>>>>511
>>>>>>>>> 61
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>72825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc
>>>>>>>>>%
>>>>>>>>>3
>>>>>>>>>D&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
>>>>>>>>>><aharui@adobe.com.INVALID
>>>>>>>>>> <ma...@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
>>>>>>>>>> <ma...@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
>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>>><ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>>>>><ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>
>>
>

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Alex Harui <ah...@adobe.com.INVALID>]

Two more thoughts on this utility.  I think you create a UID for each
child class.  I think the UID can consist of the sorted property values
and their types so for the snippet below the UID would be:

  
"baseClassname:String;description:String;members:Array;qname:String;tags:Ar
ray;type:String;"

Then before creating a new child class, you first build the UID and see if
already exists.  That way you can handle an Employee class being used in
two different fields of a Company object.

Also, you build out a cache of instances so you don't loop for references
back to parent objects.

If anyone gets started on the utility, let us know so we don't have more
than one person working on it.

Thanks,
-Alex

On 2/6/18, 9:53 AM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:

>Pretty sure something like this was done for Flash Builder.  You could
>direct FB to generate ValueObjects from a WSDL.
>
>I'm imagining an AIR app that lets you specify a path to an output folder
>and a class name and lets you paste a JSON result.
>
>If you look at the ASDoc structure for DataGrid.json, it looks like this:
>
>{ "type": "class",
>  "qname": "org.apache.royale.express.DataGrid",
>  "baseClassname": "org.apache.royale.html.DataGrid",
>  "description": "This class extends DataGrid and adds beads for drag and
>drop and column reordering.",
>  "tags": [
>     {  "tagName": "flexdocurl",
>        "values": 
>["https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflex.ap
>ache.org%2Fasdoc%2Fspark%2Fcomponents%2FDataGrid.html&data=02%7C01%7Caharu
>i%40adobe.com%7C364fbca7fc9144384fd808d56d8a96c0%7C71f1da39c0a84d5a8d88a67
>b23c30bf4%7C0%7C0%7C636535364360288547&sdata=5%2FZyPUsg30zGUdqwPxr3XFu6Qio
>FFL3%2BZ1RBl5kDADw%3D&reserved=0"]},
>     {  "tagName": "flexcomponent",
>        "values": ["spark.components.DataGrid"]}],
>  "members": [
>     { "type": "method",
>       "qname": "org.apache.royale.express.DataGrid",
>       "namespace": "",
>       "return": "",
>       "params": []},
>     { "type": "method",
>       "qname": "addedToParent",
>       "namespace": "public",
>       "override": true,
>       "return": "void",
>       "params": []}]
>}
>
>So, I might call this "ClassData".  The utility would JSON.parse the
>structure and walk each property.  If it sees the value is a String then
>it sets the property type to String, if a number, then Number or int if
>the value doesn't have decimal places.  True and false are Booleans.
>Array for Arrays.
>
>If the value is an Array, it looks at the first element in the Array.  IF
>the first element Is an Object, like it is for tags, it would create the
>class ClassData_tags and walk the object.  Same for any value of a field
>that is an Object.
>
>IMO, it doesn't have to be perfect, just save you most of the tedious
>work.  And if you don't like the generated class names, the IDEs should
>support refactoring (now or eventually).
>
>Of course, I could be wrong...
>
>-Alex
>
>
>
>On 2/6/18, 9:16 AM, "Gabe Harbs" <ha...@gmail.com> wrote:
>
>>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 <ha...@gmail.com> wrote:
>>> 
>>> What kind of utility do you have in mind?
>>> 
>>> 
>>>> On Feb 6, 2018, at 7:09 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>>>>>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" <ha...@gmail.com> 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%2Fapac
>>>>>>>h
>>>>>>>ero
>>>>>>> ya
>>>>>>> 
>>>>>>> 
>>>>>>>leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2F
>>>>>>>l
>>>>>>>ast
>>>>>>> Su
>>>>>>> 
>>>>>>> 
>>>>>>>ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicati
>>>>>>>o
>>>>>>>n-t
>>>>>>> ut
>>>>>>> 
>>>>>>> 
>>>>>>>orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b2
>>>>>>>2
>>>>>>>9e4
>>>>>>> 9b
>>>>>>> 
>>>>>>> 
>>>>>>>b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6
>>>>>>>3
>>>>>>>653
>>>>>>> 51
>>>>>>> 
>>>>>>> 
>>>>>>>16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&r
>>>>>>>e
>>>>>>>ser
>>>>>>> ve
>>>>>>> d=0 
>>>>>>> 
>>>>>>> 
>>>>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapa
>>>>>>>c
>>>>>>>her
>>>>>>> oy
>>>>>>> 
>>>>>>> 
>>>>>>>aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2
>>>>>>>F
>>>>>>>las
>>>>>>> tS
>>>>>>> 
>>>>>>> 
>>>>>>>uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicat
>>>>>>>i
>>>>>>>on-
>>>>>>> tu
>>>>>>> 
>>>>>>> 
>>>>>>>torial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b
>>>>>>>2
>>>>>>>29e
>>>>>>> 49
>>>>>>> 
>>>>>>> 
>>>>>>>bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C
>>>>>>>6
>>>>>>>365
>>>>>>> 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 <ha...@gmail.com>
>>>>>>>>wrote:
>>>>>>>> 
>>>>>>>> Related:
>>>>>>>> 
>>>>>>>> On this page:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapa
>>>>>>>>c
>>>>>>>>her
>>>>>>>> oy
>>>>>>>> 
>>>>>>>> 
>>>>>>>>aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%
>>>>>>>>2
>>>>>>>>Fla
>>>>>>>> st
>>>>>>>> 
>>>>>>>> 
>>>>>>>>SuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplic
>>>>>>>>a
>>>>>>>>tio
>>>>>>>> n-
>>>>>>>> 
>>>>>>>> 
>>>>>>>>tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49
>>>>>>>>b
>>>>>>>>b44
>>>>>>>> 3d
>>>>>>>> 
>>>>>>>> 
>>>>>>>>dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653
>>>>>>>>5
>>>>>>>>116
>>>>>>>> 17
>>>>>>>> 
>>>>>>>> 
>>>>>>>>2825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3
>>>>>>>>D
>>>>>>>>&re
>>>>>>>> se
>>>>>>>> rved=0 
>>>>>>>> 
>>>>>>>> 
>>>>>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fap
>>>>>>>>a
>>>>>>>>che
>>>>>>>> ro
>>>>>>>> 
>>>>>>>> 
>>>>>>>>yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging
>>>>>>>>%
>>>>>>>>2Fl
>>>>>>>> as
>>>>>>>> 
>>>>>>>> 
>>>>>>>>tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fappli
>>>>>>>>c
>>>>>>>>ati
>>>>>>>> on
>>>>>>>> 
>>>>>>>> 
>>>>>>>>-tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e4
>>>>>>>>9
>>>>>>>>bb4
>>>>>>>> 43
>>>>>>>> 
>>>>>>>> 
>>>>>>>>ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365
>>>>>>>>3
>>>>>>>>511
>>>>>>>> 61
>>>>>>>> 
>>>>>>>> 
>>>>>>>>72825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%
>>>>>>>>3
>>>>>>>>D&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 <aharui@adobe.com.INVALID
>>>>>>>>> <ma...@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
>>>>>>>>> <ma...@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
>>>>>>>>>>> <ma...@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
>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>><ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>>>><ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>>
>

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Alex Harui <ah...@adobe.com.INVALID>]

Pretty sure something like this was done for Flash Builder.  You could
direct FB to generate ValueObjects from a WSDL.

I'm imagining an AIR app that lets you specify a path to an output folder
and a class name and lets you paste a JSON result.

If you look at the ASDoc structure for DataGrid.json, it looks like this:

{ "type": "class",
  "qname": "org.apache.royale.express.DataGrid",
  "baseClassname": "org.apache.royale.html.DataGrid",
  "description": "This class extends DataGrid and adds beads for drag and
drop and column reordering.",
  "tags": [
     {  "tagName": "flexdocurl",
        "values": 
["https://flex.apache.org/asdoc/spark/components/DataGrid.html"]},
     {  "tagName": "flexcomponent",
        "values": ["spark.components.DataGrid"]}],
  "members": [
     { "type": "method",
       "qname": "org.apache.royale.express.DataGrid",
       "namespace": "",
       "return": "",
       "params": []},
     { "type": "method",
       "qname": "addedToParent",
       "namespace": "public",
       "override": true,
       "return": "void",
       "params": []}]
}

So, I might call this "ClassData".  The utility would JSON.parse the
structure and walk each property.  If it sees the value is a String then
it sets the property type to String, if a number, then Number or int if
the value doesn't have decimal places.  True and false are Booleans.
Array for Arrays.

If the value is an Array, it looks at the first element in the Array.  IF
the first element Is an Object, like it is for tags, it would create the
class ClassData_tags and walk the object.  Same for any value of a field
that is an Object.

IMO, it doesn't have to be perfect, just save you most of the tedious
work.  And if you don't like the generated class names, the IDEs should
support refactoring (now or eventually).

Of course, I could be wrong...

-Alex



On 2/6/18, 9:16 AM, "Gabe Harbs" <ha...@gmail.com> wrote:

>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 <ha...@gmail.com> wrote:
>> 
>> What kind of utility do you have in mind?
>> 
>> 
>>> On Feb 6, 2018, at 7:09 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID>
>>>>>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" <ha...@gmail.com> 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%2Fapach
>>>>>>ero
>>>>>> ya
>>>>>> 
>>>>>> 
>>>>>>leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Fl
>>>>>>ast
>>>>>> Su
>>>>>> 
>>>>>> 
>>>>>>ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicatio
>>>>>>n-t
>>>>>> ut
>>>>>> 
>>>>>> 
>>>>>>orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b22
>>>>>>9e4
>>>>>> 9b
>>>>>> 
>>>>>> 
>>>>>>b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63
>>>>>>653
>>>>>> 51
>>>>>> 
>>>>>> 
>>>>>>16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&re
>>>>>>ser
>>>>>> ve
>>>>>> d=0 
>>>>>> 
>>>>>> 
>>>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapac
>>>>>>her
>>>>>> oy
>>>>>> 
>>>>>> 
>>>>>>aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2F
>>>>>>las
>>>>>> tS
>>>>>> 
>>>>>> 
>>>>>>uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicati
>>>>>>on-
>>>>>> tu
>>>>>> 
>>>>>> 
>>>>>>torial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b2
>>>>>>29e
>>>>>> 49
>>>>>> 
>>>>>> 
>>>>>>bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6
>>>>>>365
>>>>>> 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 <ha...@gmail.com>
>>>>>>>wrote:
>>>>>>> 
>>>>>>> Related:
>>>>>>> 
>>>>>>> On this page:
>>>>>>> 
>>>>>>> 
>>>>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapac
>>>>>>>her
>>>>>>> oy
>>>>>>> 
>>>>>>> 
>>>>>>>aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2
>>>>>>>Fla
>>>>>>> st
>>>>>>> 
>>>>>>> 
>>>>>>>SuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplica
>>>>>>>tio
>>>>>>> n-
>>>>>>> 
>>>>>>> 
>>>>>>>tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49b
>>>>>>>b44
>>>>>>> 3d
>>>>>>> 
>>>>>>> 
>>>>>>>dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535
>>>>>>>116
>>>>>>> 17
>>>>>>> 
>>>>>>> 
>>>>>>>2825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
>>>>>>>&re
>>>>>>> se
>>>>>>> rved=0 
>>>>>>> 
>>>>>>> 
>>>>>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapa
>>>>>>>che
>>>>>>> ro
>>>>>>> 
>>>>>>> 
>>>>>>>yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%
>>>>>>>2Fl
>>>>>>> as
>>>>>>> 
>>>>>>> 
>>>>>>>tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplic
>>>>>>>ati
>>>>>>> on
>>>>>>> 
>>>>>>> 
>>>>>>>-tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49
>>>>>>>bb4
>>>>>>> 43
>>>>>>> 
>>>>>>> 
>>>>>>>ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653
>>>>>>>511
>>>>>>> 61
>>>>>>> 
>>>>>>> 
>>>>>>>72825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3
>>>>>>>D&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 <aharui@adobe.com.INVALID
>>>>>>>> <ma...@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
>>>>>>>> <ma...@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
>>>>>>>>>> <ma...@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
>>>>>>>>>>> <ma...@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
>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>><ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>>><ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Gabe Harbs <ha...@gmail.com>]

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 <ha...@gmail.com> wrote:
> 
> What kind of utility do you have in mind?
> 
> 
>> On Feb 6, 2018, at 7:09 PM, Alex Harui <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ha...@gmail.com> 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 <aharui@adobe.com.INVALID
>>>>>>> <ma...@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
>>>>>>> <ma...@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
>>>>>>>>> <ma...@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
>>>>>>>>>> <ma...@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
>>>>>>>>>> <ma...@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
>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>> <ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>>>> <ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Gabe Harbs <ha...@gmail.com>]

What kind of utility do you have in mind?


> On Feb 6, 2018, at 7:09 PM, Alex Harui <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ha...@gmail.com> 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 <aharui@adobe.com.INVALID
>>>>>> <ma...@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
>>>>>> <ma...@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
>>>>>>>> <ma...@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
>>>>>>>>> <ma...@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
>>>>>>>>> <ma...@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
>>>>>>>>>>> <ma...@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
>>>>>>>>>>> <ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>>> <ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>>> <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Alex Harui <ah...@adobe.com.INVALID>]

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" <ha...@gmail.com> 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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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 <ha...@gmail.com> 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 <aharui@adobe.com.INVALID
>>>>> <ma...@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
>>>>> <ma...@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
>>>>>>> <ma...@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
>>>>>>>> <ma...@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
>>>>>>>> <ma...@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
>>>>>>>>>> <ma...@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
>>>>>>>>>> <ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>> <ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>>><ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Gabe Harbs <ha...@gmail.com>]

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 <ah...@adobe.com.INVALID> 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" <ha...@gmail.com> 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%2Fapacheroya
>> leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2FlastSu
>> ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-tut
>> orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49b
>> b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351
>> 16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&reserve
>> d=0 
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheroy
>> aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2FlastS
>> uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-tu
>> torial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49
>> bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535
>> 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 <ha...@gmail.com> wrote:
>>> 
>>> Related:
>>> 
>>> On this page: 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheroy
>>> aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flast
>>> SuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-
>>> tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443d
>>> dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511617
>>> 2825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&rese
>>> rved=0 
>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachero
>>> yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flas
>>> tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication
>>> -tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443
>>> ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351161
>>> 72825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&res
>>> 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 <aharui@adobe.com.INVALID
>>>> <ma...@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
>>>> <ma...@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
>>>>>> <ma...@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
>>>>>>> <ma...@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
>>>>>>> <ma...@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
>>>>>>>>> <ma...@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
>>>>>>>>> <ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>> <ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>>> <ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Alex Harui <ah...@adobe.com.INVALID>]

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" <ha...@gmail.com> 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%2Fapacheroya
>leci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2FlastSu
>ccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-tut
>orial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49b
>b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351
>16172815360&sdata=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&reserve
>d=0 
><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheroy
>aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2FlastS
>uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-tu
>torial%2Fvalue-objects.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49
>bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535
>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 <ha...@gmail.com> wrote:
>> 
>> Related:
>> 
>> On this page: 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapacheroy
>>aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flast
>>SuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-
>>tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443d
>>dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511617
>>2825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&rese
>>rved=0 
>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapachero
>>yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flas
>>tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication
>>-tutorial%2Fdata.html&data=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443
>>ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351161
>>72825365&sdata=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D&res
>>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 <aharui@adobe.com.INVALID
>>><ma...@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
>>><ma...@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
>>>>><ma...@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
>>>>>><ma...@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
>>>>>><ma...@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
>>>>>>>><ma...@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
>>>>>>>><ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>><ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <harbs.lists@gmail.com
>>>>>>>>>>>><ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Gabe Harbs <ha...@gmail.com>]

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 <ha...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <harbs.lists@gmail.com <ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <harbs.lists@gmail.com <ma...@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 <ma...@adobe.com.INVALID>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Gabe Harbs <ha...@gmail.com>]

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 <ah...@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" <ha...@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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>>> 
>>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Alex Harui <ah...@adobe.com.INVALID>]

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" <ha...@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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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
>>>>>>>>><ah...@adobe.com.INVALID>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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
>>>>>>>>>>><ah...@adobe.com.INVALID>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>>> 
>>>>>>>>>>> Do you mean SWF support?
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Gabe Harbs <ha...@gmail.com>]

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 <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID>
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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 <ah...@adobe.com.INVALID>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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 <ah...@adobe.com.INVALID>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>>> 
>>>>>>>>>> Do you mean SWF support?
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)

[Gabe Harbs <ha...@gmail.com>]

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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@adobe.com.INVALID>
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs" <ha...@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 <ah...@adobe.com.INVALID>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 2/4/18, 1:10 AM, "Gabe Harbs" <ha...@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 <ah...@adobe.com.INVALID>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> 1. Why is bin-release not working?
>>>>>>>>> 
>>>>>>>>> Do you mean SWF support?
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>