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

[Alex Harui]

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"  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"  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=02%7C01%7Cahar
>>u
>>i%40adobe.com%7C364fbca7fc9144384fd808d56d8a96c0%7C71f1da39c0a84d5a8d88a6
>>7
>>b23c30bf4%7C0%7C0%7C636535364360288547=5%2FZyPUsg30zGUdqwPxr3XFu6Qi
>>o
>>FFL3%2BZ1RBl5kDADw%3D=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"  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  wrote:
 
 What kind of utility do you have in mind?
 
 
> On Feb 6, 2018, at 7:09 PM, Alex Harui 
>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"  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…

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

[Dave Fisher]

Sent from my iPhone

> On Feb 8, 2018, at 2:10 PM, Alex Harui  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.rov...@gmail.com on behalf of Carlos Rovira"
>  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 :
>> 
>>> 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.rov...@gmail.com on behalf of Carlos
>>> Rovira"
>>>  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 :
 
> 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 

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

[Alex Harui]

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.rov...@gmail.com on behalf of Carlos Rovira"
 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 :
>
>> 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.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>  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 :
>> >
>> >> 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, 

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

[Carlos Rovira]

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 :

> 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.rov...@gmail.com on behalf of Carlos Rovira"
>  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 :
> >
> >> 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  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 
> >> 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"  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.
> 

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

[Alex Harui]

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.rov...@gmail.com on behalf of Carlos Rovira"
 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 :
>
>> 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  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 
>> 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"  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 
>> > >>> 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
>> 

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

[Josh Tynjala]

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

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

[Alex Harui]

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"  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=02%7C01%7Caharu
>i%40adobe.com%7C364fbca7fc9144384fd808d56d8a96c0%7C71f1da39c0a84d5a8d88a67
>b23c30bf4%7C0%7C0%7C636535364360288547=5%2FZyPUsg30zGUdqwPxr3XFu6Qio
>FFL3%2BZ1RBl5kDADw%3D=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"  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  wrote:
>>> 
>>> What kind of utility do you have in mind?
>>> 
>>> 
 On Feb 6, 2018, at 7:09 PM, Alex Harui 
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"  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 
>>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 

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

[Alex Harui]

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"  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  wrote:
>> 
>> What kind of utility do you have in mind?
>> 
>> 
>>> On Feb 6, 2018, at 7:09 PM, Alex Harui 
>>>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"  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 
>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"  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=02%7C01%7Caharui%40adobe.com%7C924b22
>>9e4
>> 9b
>> 
>> 
>>b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63
>>653

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

[OmPrakash Muppirala]

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"  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  wrote:
> >
> > What kind of utility do you have in mind?
> >
> >
> >> On Feb 6, 2018, at 7:09 PM, Alex Harui 
> 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"  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 
> 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"  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=02%7C01%7Caharui%40adobe.com
> %7C924b229e4
> > 9b
> >
> > b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C63653
> > 51
> >
> > 16172815360=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D&
> reser
> > ve
> > d=0
> >
> >  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=02%7C01%7Caharui%40adobe.com
> %7C924b229e
> > 49
> >
> > bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c3
> 0bf4%7C0%7C0%7C6365
> > 35
> >
> > 116172825365=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 
> 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-
> >>
> >> 

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

[Gabe Harbs]

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  wrote:
> 
> What kind of utility do you have in mind?
> 
> 
>> On Feb 6, 2018, at 7:09 PM, Alex Harui  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"  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  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"  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=02%7C01%7Caharui%40adobe.com%7C924b229e4
> 9b
> 
> b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653
> 51
> 
> 16172815360=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D
> ve
> d=0 
> 
>  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=02%7C01%7Caharui%40adobe.com%7C924b229e
> 49
> 
> bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365
> 35
> 
> 116172825365=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  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=02%7C01%7Caharui%40adobe.com%7C924b229e49bb44
>> 3d
>> 
>> dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535116
>> 17
>> 
>> 2825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
>> se
>> rved=0 
>> 
>> > ro
>> 
>> yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Fl
>> as
>> 
>> tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicati
>> on
>> 
>> -tutorial%2Fdata.html=02%7C01%7Caharui%40adobe.com%7C924b229e49bb4
>> 43
>> 
>> ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511
>> 61
>> 

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

[Gabe Harbs]

What kind of utility do you have in mind?


> On Feb 6, 2018, at 7:09 PM, Alex Harui  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"  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  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"  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=02%7C01%7Caharui%40adobe.com%7C924b229e4
 9b
 
 b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653
 51
 
 16172815360=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D
 ve
 d=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  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=02%7C01%7Caharui%40adobe.com%7C924b229e49bb44
> 3d
> 
> dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535116
> 17
> 
> 2825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
> se
> rved=0 
> 
>  ro
> 
> yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Fl
> as
> 
> tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplicati
> on
> 
> -tutorial%2Fdata.html=02%7C01%7Caharui%40adobe.com%7C924b229e49bb4
> 43
> 
> ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511
> 61
> 
> 72825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
> es
> erved=0>
> 
> Shouldn’t the following code have trouble with minification?
> 
> {
> repos = configurator.json.repos;
> projectName = configurator.json.projectName;
> }
> 
> What’s 

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

[Alex Harui]

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"  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  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"  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=02%7C01%7Caharui%40adobe.com%7C924b229e4
>>>9b
>>> 
>>>b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653
>>>51
>>> 
>>>16172815360=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D
>>>ve
>>> d=0 
>>> 
>>>>>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=02%7C01%7Caharui%40adobe.com%7C924b229e
>>>49
>>> 
>>>bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365
>>>35
>>> 
>>>116172825365=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  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=02%7C01%7Caharui%40adobe.com%7C924b229e49bb44
3d
 
dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535116
17
 
2825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
se
 rved=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  > 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

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

[Gabe Harbs]

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  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"  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=02%7C01%7Caharui%40adobe.com%7C924b229e49b
>> b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351
>> 16172815360=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D
>> d=0 
>> > aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2FlastS
>> uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-tu
>> torial%2Fvalue-objects.html=02%7C01%7Caharui%40adobe.com%7C924b229e49
>> bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535
>> 116172825365=3m3kTW910JYWV8MaM4%2F%2B3v82l5EvxIqgRjqAtIC7N%2BU%3D
>> 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  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=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443d
>>> dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511617
>>> 2825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
>>> rved=0 
>>> >> yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flas
>>> tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication
>>> -tutorial%2Fdata.html=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443
>>> ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351161
>>> 72825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
>>> 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 > 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" > 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 

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

[Alex Harui]

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"  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=02%7C01%7Caharui%40adobe.com%7C924b229e49b
>b443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351
>16172815360=e9FoFwJfNJfjmFlWF4%2FRIwCNU4R5mhEEQ9GYz70W3Ls%3D
>d=0 
>aleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2FlastS
>uccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication-tu
>torial%2Fvalue-objects.html=02%7C01%7Caharui%40adobe.com%7C924b229e49
>bb443ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C636535
>116172825365=3m3kTW910JYWV8MaM4%2F%2B3v82l5EvxIqgRjqAtIC7N%2BU%3D
>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  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=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443d
>>dbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C63653511617
>>2825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
>>rved=0 
>>>yaleci.westus2.cloudapp.azure.com%3A8080%2Fjob%2FRoyaleDocs_Staging%2Flas
>>tSuccessfulBuild%2Fartifact%2F_site%2Fcreate-an-application%2Fapplication
>>-tutorial%2Fdata.html=02%7C01%7Caharui%40adobe.com%7C924b229e49bb443
>>ddbf708d56d50cd97%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%7C6365351161
>>72825365=IgeSJZENyrUXHWMMzG7U5ZIBYdBe5so%2BeO81N%2B1u%2B%2Fc%3D
>>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 >>> 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" >>> 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 > 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

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

[Gabe Harbs]

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
 


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  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
>  
> 
> 
> 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 > > 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" > > 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 > 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  >
> 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"  > wrote:
> 
>> Yeah. That’s what 

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

[Gabe Harbs]

Related:

On this page: 
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  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"  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  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 
 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"  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.
> 
> 

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

[Piotr Zarzycki]

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 :

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

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

[Gabe Harbs]

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  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"  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  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"  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 
> 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"  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 
>>> wrote:
>>> 
>>> In theory, everything you say is true. It might even be good
>>> practice.
>>> 
>>> I’m telling you that this was 

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

[Alex Harui]

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

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

[Alex Harui]

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

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

[Alex Harui]

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

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

[Gabe Harbs]

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

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

[Gabe Harbs]

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  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"  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  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"  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"];
 
 

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

[Alex Harui]

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"  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  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"  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 
wrote:
 
 
 
 On 2/5/18, 2:01 AM, "Gabe Harbs"  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