royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlosrov...@apache.org>
Subject Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)
Date Thu, 08 Feb 2018 21:55:28 GMT
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 <aharui@adobe.com.invalid>:

> I'm not disagreeing. I think the question is whether we need yet another
> compiler option to generate bracket notation for objects or just ask folks
> to use SIMPLE_OPTIMIZATIONS.  And whether we switch to
> SIMPLE_OPTIMIZATIONS by default.  I can think of lots of other things to
> work on besides this new option if we have rough equivalents.
>
> -Alex
>
> On 2/8/18, 10:36 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
> <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org> wrote:
>
> >Although I'm pro typed,  I agree with Josh that we should not enforce
> >that.
> >That's one of the great points in Flash/Flex.
> >For make things quick, I use simple objects with bracket notation, when
> >the
> >application is more relevant I go the right typed path.
> >It's up to the developer decide when they want one or another.
> >
> >
> >
> >2018-02-08 18:50 GMT+01:00 Josh Tynjala <joshtynjala@apache.org>:
> >
> >> Nothing frustrated me more about Royale/FlexJS than the fact that I
> >> couldn't use untyped objects without bracket notation. It's a very bad
> >>user
> >> experience when trying to consume JSON, or even when choosing to create
> >>my
> >> own object literals. While it's a good best practice to create value
> >> objects, that shouldn't be forced on everyone. I frequently use untyped
> >> objects when prototyping because it's more convenient. They're also
> >>useful
> >> in example code to reduce boilerplate that isn't particularly relevant
> >>to
> >> the concept/feature that you're trying to demonstrate. And, of course,
> >> there's the already mentioned JSON.
> >>
> >> In the past, I kept trying to advocate making SIMPLE_OPTIMIZATIONS the
> >> default instead of ADVANCED_OPTIMIZATIONS. In my opinion the slightly
> >> larger file size is an acceptable trade off, if it reduces the
> >>frustration
> >> of this situation. Especially for new users who will absolutely think
> >>its a
> >> serious bug in the Royale compiler. However, as Harbs notes here, if the
> >> compiler were a little smarter, ADVANCED_OPTIMIZATIONS could be
> >>retained.
> >> The compiler could generate code differently when something resolves as
> >>the
> >> Object type. The emitter could translate dot notation normally most of
> >>the
> >> time, and let ADVANCED_OPTIMIZATIONS do its renaming. However, if it
> >> detects Object, switch to bracket notation instead. I believe it would
> >>also
> >> need to add quotes around properties defined in object literals.
> >>
> >> Ideally, the following code should work properly out of the box:
> >>
> >> var obj:Object = {one: 1, "two": 2};
> >> obj.three = 3;
> >> obj["four"] = 4;
> >> var one:Number = obj["one"];
> >> var two:Number = obj.two;
> >> var three:Number = obj["three"];
> >> var four:Number = obj.four;
> >>
> >> The compiler would probably emit something like this to make it work
> >>with
> >> the Closure compiler's ADVANCED_OPTIMIZATIONS:
> >>
> >> var obj:Object = {"one": 1, "two": 2};
> >> obj["three"] = 3;
> >> obj["four"] = 4;
> >> var one:Number = obj["one"];
> >> var two:Number = obj["two"];
> >> var three:Number = obj["three"];
> >> var four:Number = obj["four"];
> >>
> >> Again, that's only for when something is typed as Object. If something
> >> actually has a class, let Closure compiler go nuts and rename
> >>everything it
> >> wants.
> >>
> >> - Josh
> >>
> >> On 2018/02/06 08:51:19, Gabe Harbs <harbs.lists@gmail.com> wrote:
> >> > Quite sure. In my angular app I was using an older version of the
> >> closure compiler to minify the js files. I was using the default options
> >> which clearly does not use ADVANCED_OPTIMIZATIONS, so the object
> >>literals
> >> didn’t get renamed.
> >> >
> >> > I think most modern app frameworks use other tools such as Babel for
> >> magnification, but I believe that handles object literals correctly too.
> >> >
> >> > We definitely want to use ADVANCED_OPTIMIZATIONS, but that’s killing
> >> object literals. I’m proposing a compiler *option* to allow to continue
> >> using ADVANCED_OPTIMIZATIONS, but prevent renaming on objects which
> >>should
> >> not be renamed.
> >> >
> >> > Harbs
> >> >
> >> > > On Feb 6, 2018, at 9:38 AM, Alex Harui <aharui@adobe.com.INVALID>
> >> wrote:
> >> > >
> >> > > Are you sure Angular and React minify your code instead of running
> >>it
> >> > > against their minified framework?
> >> > >
> >> > > -Alex
> >> > >
> >> > > On 2/5/18, 11:22 PM, "Gabe Harbs" <harbs.lists@gmail.com> wrote:
> >> > >
> >> > >>> Maybe I'm missing something.  I don't think Royale has any
extra
> >> > >>> problems
> >> > >>> with JSON objects than other JS Frameworks have.  If you want
to
> >> minify,
> >> > >>> you have to use brackets and strings.
> >> > >>
> >> > >> It does.
> >> > >>
> >> > >> I’ve written angular apps and I’ve never had to worry about
using
> >> bracket
> >> > >> notation for minifying simple js objects. I’m pretty sure the
same
> >>is
> >> for
> >> > >> React, etc.
> >> > >>
> >> > >>> On Feb 5, 2018, at 11:34 PM, Alex Harui <aharui@adobe.com.INVALID
> >
> >> > >>> wrote:
> >> > >>>
> >> > >>> Maybe I'm missing something.  I don't think Royale has any
extra
> >> > >>> problems
> >> > >>> with JSON objects than other JS Frameworks have.  If you want
to
> >> minify,
> >> > >>> you have to use brackets and strings.  If you don't want to
> >>minify,
> >> then
> >> > >>> you don't need to worry about that.  Am I wrong about that?
> >> > >>>
> >> > >>>
> >> > >>> JSON has something like a "reviver".  Has anyone played with
that
> >>to
> >> see
> >> > >>> if it can be used to convert straight to VO's?
> >> > >>>
> >> > >>> Thanks,
> >> > >>> -Alex
> >> > >>>
> >> > >>> On 2/5/18, 1:08 PM, "Gabe Harbs" <harbs.lists@gmail.com>
wrote:
> >> > >>>
> >> > >>>> An additional point:
> >> > >>>>
> >> > >>>> How do you propose handling json that’s multiple levels
deep?
> >>Walk
> >> the
> >> > >>>> json and construct VOs on each level? That seems to me
just as
> >>bad
> >> as
> >> > >>>> the
> >> > >>>> problem. Imagine you just want foo.baz.thingy.uid? You’d
need to
> >> > >>>> create a
> >> > >>>> VO of foo, baz and thingy or be forced to use
> >> > >>>> foo[“baz”][“thingy”][“uid”]. Of course the
average user is not
> >> going to
> >> > >>>> remember to do that until their release build doesn’t
work…
> >> > >>>>
> >> > >>>> Creating VOs means you can’t simply use JSON.parse().
You’d need
> >> your
> >> > >>>> own
> >> > >>>> parser for each type of json you’re consuming. OK. Maybe
not full
> >> > >>>> parsing, but the constructors for these VOs will get pretty
> >>messy —
> >> > >>>> especially if the structure is a bit fluid.
> >> > >>>>
> >> > >>>> Harbs
> >> > >>>>
> >> > >>>>
> >> > >>>>> On Feb 5, 2018, at 10:36 PM, Gabe Harbs <harbs.lists@gmail.com>
> >> wrote:
> >> > >>>>>
> >> > >>>>> In theory, everything you say is true. It might even
be good
> >> practice.
> >> > >>>>>
> >> > >>>>> I’m telling you that this was a pain point when
migrating my
> >>app.
> >> > >>>>> Simply declaring types as VOs didn't solve the problem
for me.
> >>The
> >> way
> >> > >>>>> I’ve found that’s needed to solve the problem
was passing the
> >> object
> >> > >>>>> literal into a VO constructor and declaring the variables
using
> >> > >>>>> bracketed access. I was likely going about it wrong,
but it was
> >> easier
> >> > >>>>> to just go with the bracketed literals.
> >> > >>>>>
> >> > >>>>> Again: Suggesting using VOs (if we can figure out
easy
> >> instructions to
> >> > >>>>> do so) is probably a good idea and better recommended
practice,
> >>but
> >> > >>>>> people live on the edge using other JS frameworks,
and I’d
> >>rather
> >> not
> >> > >>>>> make it harder than it needs to be if they do want
to use
> >>untyped
> >> > >>>>> object
> >> > >>>>> literals.
> >> > >>>>>
> >> > >>>>> Harbs
> >> > >>>>>
> >> > >>>>>> On Feb 5, 2018, at 8:01 PM, Alex Harui
> >><aharui@adobe.com.INVALID>
> >> > >>>>>> wrote:
> >> > >>>>>>
> >> > >>>>>> It was great to skip type-checking in Flash at
times, but the
> >> runtime
> >> > >>>>>> was
> >> > >>>>>> also strongly typed.  Also, JS was not a practical
language for
> >> > >>>>>> Flash.
> >> > >>>>>> It
> >> > >>>>>> is more risky to do skip type-checking in Royale
for JS.  These
> >> new
> >> > >>>>>> cars
> >> > >>>>>> with lane warnings are a rough analogy.  They
only let you be
> >>less
> >> > >>>>>> attentive on nice new painted highways.  Flash's
runtime
> >>wouldn't
> >> let
> >> > >>>>>> you
> >> > >>>>>> make type mismatches so it effectively had lane
lines.  JS is a
> >> road
> >> > >>>>>> without lane lines.  A ValueObject keeps your
eyes on the road.
> >> An
> >> > >>>>>> ounce
> >> > >>>>>> of prevention is better than a pound of cure.
> >> > >>>>>>
> >> > >>>>>> IMO, you might be better off writing a bead that
you can pass a
> >> JSON
> >> > >>>>>> object and it will generate the AS class for you
to copy from
> >>the
> >> > >>>>>> clipboard and paste into a file.  Then you could
guess at the
> >> types.
> >> > >>>>>> That
> >> > >>>>>> wouldn't require compiler changes and would encourage
early
> >> > >>>>>> prevention.
> >> > >>>>>>
> >> > >>>>>> Just an idea,
> >> > >>>>>> -Alex
> >> > >>>>>>
> >> > >>>>>> On 2/5/18, 9:39 AM, "Gabe Harbs" <harbs.lists@gmail.com>
> wrote:
> >> > >>>>>>
> >> > >>>>>>> Yeah. That’s what you’ve argued in the
past, and in a pure
> >>world
> >> > >>>>>>> you’d be
> >> > >>>>>>> right.
> >> > >>>>>>>
> >> > >>>>>>> However, I’d prefer the option to be practical
when dealing
> >>with
> >> > >>>>>>> more
> >> > >>>>>>> data types. Being forced to fiddle with properly
typed objects
> >> > >>>>>>> *always*
> >> > >>>>>>> is too confining IMO. What I personally ended
up doing when
> >> dealing
> >> > >>>>>>> with
> >> > >>>>>>> APIs and the like was the make sure to quote
everything in my
> >>app
> >> > >>>>>>> rather
> >> > >>>>>>> than declare VOs even though finding all the
instances were a
> >> pain.
> >> > >>>>>>>
> >> > >>>>>>> I think it’s pretty common for folks to
use untyped objects
> >> > >>>>>>> *especially*
> >> > >>>>>>> when dealing with APIs in classic Flex apps.
It seem overly
> >> > >>>>>>> draconian
> >> > >>>>>>> to
> >> > >>>>>>> make that a requirement for Royale.
> >> > >>>>>>>
> >> > >>>>>>> Part of the attraction of ActionScript has
been that it’s
> >> > >>>>>>> *optionally*
> >> > >>>>>>> typed. Minification in JS makes the optional
typing pretty
> >>weak.
> >> > >>>>>>>
> >> > >>>>>>>> If you don't care about SWF support, you
can quickly make
> >> > >>>>>>>> ValueObjects
> >> > >>>>>>>> just for the compiler.
> >> > >>>>>>>
> >> > >>>>>>> Quickly? I’m not sure how.
> >> > >>>>>>>
> >> > >>>>>>> My $0.02.
> >> > >>>>>>> Harbs
> >> > >>>>>>>
> >> > >>>>>>>> On Feb 5, 2018, at 7:28 PM, Alex Harui
> >><aharui@adobe.com.INVALID
> >> >
> >> > >>>>>>>> wrote:
> >> > >>>>>>>>
> >> > >>>>>>>> IMO, your proposal sort of defeats the
purpose of
> >>ActionScript
> >> and
> >> > >>>>>>>> Royale,
> >> > >>>>>>>> which is to provide a type system at compile
time.  Not only
> >> should
> >> > >>>>>>>> you
> >> > >>>>>>>> want to address your JSON fields, but
you should want to have
> >> them
> >> > >>>>>>>> type-checked, and that you spelled the
field name correctly.
> >> > >>>>>>>> Otherwise,
> >> > >>>>>>>> the compiler is going to also allow you
to mistype:
> >> > >>>>>>>>
> >> > >>>>>>>> var name = myProps["nme"];
> >> > >>>>>>>>
> >> > >>>>>>>>
> >> > >>>>>>>> And there will be no errors.  And similarly:
> >> > >>>>>>>>
> >> > >>>>>>>> var myObj:Object = {
> >> > >>>>>>>> nme: "foo",
> >> > >>>>>>>> age : 30.1415
> >> > >>>>>>>> }
> >> > >>>>>>>>
> >> > >>>>>>>> Will be allowed when it probably shouldn't.
 And also, you
> >>could
> >> > >>>>>>>> then
> >> > >>>>>>>> use
> >> > >>>>>>>> myObj when you intended to use myOtherObj
and nobody will
> >>know
> >> > >>>>>>>> until
> >> > >>>>>>>> you
> >> > >>>>>>>> try to debug in JS.
> >> > >>>>>>>>
> >> > >>>>>>>>
> >> > >>>>>>>> If you don't care about SWF support, you
can quickly make
> >> > >>>>>>>> ValueObjects
> >> > >>>>>>>> just for the compiler.  In ASDoc, the
ValueObject is never
> >> > >>>>>>>> instantiated.
> >> > >>>>>>>> It is just like a typedef for the compiler.
> >> > >>>>>>>>
> >> > >>>>>>>> HTH,
> >> > >>>>>>>> -Alex
> >> > >>>>>>>>
> >> > >>>>>>>> On 2/5/18, 8:43 AM, "Gabe Harbs" <harbs.lists@gmail.com>
> >>wrote:
> >> > >>>>>>>>
> >> > >>>>>>>>>> JSON Objects are not destroyed.
> >> > >>>>>>>>>
> >> > >>>>>>>>> Yeah. I know, but untyped js literals
are pretty much
> >>useless
> >> in
> >> > >>>>>>>>> minified
> >> > >>>>>>>>> Royale apps.
> >> > >>>>>>>>>
> >> > >>>>>>>>>> Propose a way to determine that
a data structure
> >> > >>>>>>>>>> is external and what the compiler
should generate and
> >> implement
> >> > >>>>>>>>>> it.
> >> > >>>>>>>>>> IMO,
> >> > >>>>>>>>>> the answer is to create ValueObjects.
 That is essentially
> >> > >>>>>>>>>> typedefs
> >> > >>>>>>>>>> and
> >> > >>>>>>>>>> AFAIK, there is no way to automate
typedef generation.
> >> > >>>>>>>>>
> >> > >>>>>>>>> I already made a suggestion once:
> >> > >>>>>>>>>
> >> > >>>>>>>>> For untyped Objects, the compiler
could convert dot
> >>notation to
> >> > >>>>>>>>> bracket
> >> > >>>>>>>>> notation.
> >> > >>>>>>>>>
> >> > >>>>>>>>> The other half of that would be to
convert all object
> >>literals
> >> to
> >> > >>>>>>>>> “quoted” literals automatically.
> >> > >>>>>>>>>
> >> > >>>>>>>>> So if I have a function:
> >> > >>>>>>>>>
> >> > >>>>>>>>> function parseMyJson(json:String):Object{
> >> > >>>>>>>>>     return JSON.parse(json);
> >> > >>>>>>>>> }
> >> > >>>>>>>>>
> >> > >>>>>>>>> var myProps:Object = parseMyJson(json);
> >> > >>>>>>>>>
> >> > >>>>>>>>> var name:string = myProps.name;
> >> > >>>>>>>>>
> >> > >>>>>>>>> Would become:
> >> > >>>>>>>>>
> >> > >>>>>>>>> function parseMyJson(json){
> >> > >>>>>>>>>     return JSON.parse(json);
> >> > >>>>>>>>> }
> >> > >>>>>>>>>
> >> > >>>>>>>>> var myProps = parseMyJson(json);
> >> > >>>>>>>>>
> >> > >>>>>>>>> var name = myProps["name"];
> >> > >>>>>>>>>
> >> > >>>>>>>>> And this:
> >> > >>>>>>>>> var myObj:Object = {
> >> > >>>>>>>>>     name: "foo",
> >> > >>>>>>>>>     age : 30
> >> > >>>>>>>>> }
> >> > >>>>>>>>>
> >> > >>>>>>>>> Would become:
> >> > >>>>>>>>> var myObj = {
> >> > >>>>>>>>>     "name": "foo",
> >> > >>>>>>>>>     "age" : 30
> >> > >>>>>>>>> }
> >> > >>>>>>>>>
> >> > >>>>>>>>> These two features would have solved
almost all minification
> >> > >>>>>>>>> issues
> >> > >>>>>>>>> I’ve
> >> > >>>>>>>>> run into.
> >> > >>>>>>>>>
> >> > >>>>>>>>> I’d love to work on this myself,
but I’m still not up to
> >>making
> >> > >>>>>>>>> any
> >> > >>>>>>>>> major
> >> > >>>>>>>>> changes to the compiler… :-(
> >> > >>>>>>>>>
> >> > >>>>>>>>>> On Feb 5, 2018, at 6:13 PM, Alex
Harui
> >> <aharui@adobe.com.INVALID>
> >> > >>>>>>>>>> wrote:
> >> > >>>>>>>>>>
> >> > >>>>>>>>>>
> >> > >>>>>>>>>>
> >> > >>>>>>>>>> On 2/5/18, 2:01 AM, "Gabe Harbs"
<harbs.lists@gmail.com>
> >> wrote:
> >> > >>>>>>>>>>
> >> > >>>>>>>>>>> I’ll try to work on this.
It’s pretty slow loading the
> >>debug
> >> > >>>>>>>>>>> build.
> >> > >>>>>>>>>>>
> >> > >>>>>>>>>>> I still maintain there should
be a compiler setting or
> >> language
> >> > >>>>>>>>>>> feature
> >> > >>>>>>>>>>> to prevent objects produced
from JSON being destroyed on
> >> > >>>>>>>>>>> minification.
> >> > >>>>>>>>>>
> >> > >>>>>>>>>> JSON Objects are not destroyed.
 The code referencing their
> >> > >>>>>>>>>> fields
> >> > >>>>>>>>>> by
> >> > >>>>>>>>>> name
> >> > >>>>>>>>>> has those names changed.  Propose
a way to determine that a
> >> data
> >> > >>>>>>>>>> structure
> >> > >>>>>>>>>> is external and what the compiler
should generate and
> >> implement
> >> > >>>>>>>>>> it.
> >> > >>>>>>>>>> IMO,
> >> > >>>>>>>>>> the answer is to create ValueObjects.
 That is essentially
> >> > >>>>>>>>>> typedefs
> >> > >>>>>>>>>> and
> >> > >>>>>>>>>> AFAIK, there is no way to automate
typedef generation.
> >> > >>>>>>>>>>
> >> > >>>>>>>>>> Also, you can turn off minification
for the app as a whole.
> >> > >>>>>>>>>>
> >> > >>>>>>>>>> Other ideas welcome,
> >> > >>>>>>>>>> -Alex
> >> > >>>>>>>>>>
> >> > >>>>>>>>>>> This remains a pain point
for developing apps and having
> >>to
> >> > >>>>>>>>>>> create
> >> > >>>>>>>>>>> VOs
> >> > >>>>>>>>>>> for every API is a drag.
> >> > >>>>>>>>>>>
> >> > >>>>>>>>>>>> On Feb 5, 2018, at 10:21
AM, Alex Harui
> >> > >>>>>>>>>>>> <aharui@adobe.com.INVALID>
> >> > >>>>>>>>>>>> wrote:
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>> On 2/4/18, 1:10 AM, "Gabe
Harbs" <harbs.lists@gmail.com>
> >> wrote:
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>>> Typo. I meant js-reease.
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>> Yeah, at some later point
in time someone should build
> >>Value
> >> > >>>>>>>>>>>> Objects
> >> > >>>>>>>>>>>> for
> >> > >>>>>>>>>>>> the JSON and get js-release
working.  Maybe after this
> >> release.
> >> > >>>>>>>>>>>> I'm
> >> > >>>>>>>>>>>> just
> >> > >>>>>>>>>>>> trying to make the ASDoc
useful.
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>> I'm going to add Events
to the class detail page and
> >>anchor
> >> > >>>>>>>>>>>> links
> >> > >>>>>>>>>>>> from
> >> > >>>>>>>>>>>> the
> >> > >>>>>>>>>>>> lists to the details and
maybe a simple search-for-class
> >> > >>>>>>>>>>>> feature,
> >> > >>>>>>>>>>>> then I
> >> > >>>>>>>>>>>> think it will be time
for a release.
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>> -Alex
> >> > >>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>> On Feb 4, 2018,
at 8:08 AM, Alex Harui
> >> > >>>>>>>>>>>>>> <aharui@adobe.com.INVALID>
> >> > >>>>>>>>>>>>>> wrote:
> >> > >>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>>> 1. Why is
bin-release not working?
> >> > >>>>>>>>>>>>>>
> >> > >>>>>>>>>>>>>> Do you mean SWF
support?
> >> > >>>>>>>>>>>>>
> >> > >>>>>>>>>>>>
> >> > >>>>>>>>>>>
> >> > >>>>>>>>>>
> >> > >>>>>>>>>
> >> > >>>>>>>>
> >> > >>>>>>>
> >> > >>>>>>
> >> > >>>>>
> >> > >>>>
> >> > >>>
> >> > >>
> >> > >
> >> >
> >> >
> >>
> >
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C16f65e18ee564aa421b308d5
> >6f22fef3%7C71f1da39c0a84d5a8d88a67b23c30bf4%7C0%7C0%
> 7C636537118603984962&s
> >data=bFel9Zwl4bBQWQNBB0UqK5j36pUSXjph1yeExZQOwjw%3D&reserved=0
>
>


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

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