royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piotr Zarzycki <piotrzarzyck...@gmail.com>
Subject Re: JSON Objects renaming (was Re: ASDoc, Routing, Releases)
Date Tue, 06 Feb 2018 09:36:33 GMT
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 <harbs.lists@gmail.com>:

> I’m suggesting we have a compiler option to do it for all Object-typed
> properties. This problem is not limited to objects coming from JSON.
>
> The bracket access gets converted to dot access when google minifies the
> code, so there’s no effect on the minified code other than preventing the
> renaming.
>
> I’m all for making using value objects easier too.
>
> You lost me on the part about SOAP.
>
> Harbs
>
> > On Feb 6, 2018, at 11:05 AM, Alex Harui <aharui@adobe.com.INVALID>
> wrote:
> >
> > I'm not convinced we can know when to generate obj.property vs
> > obj["property"] unless we do it for all Objects, not just ones that came
> > from JSON.  Or for all property access.  And that is at least 3 extra
> > characters per access for anything that isn't JSON.
> >
> > I would rather we find ways to make use of ValueObjects easier.  IMO,
> type
> > information will make development faster by catching errors sooner, and
> > has the potential to make the runtime performance faster, especially if
> we
> > consider other targets besides JS some day.
> >
> > To me, the problem is roughly the same as XML decoding into ValueObjects.
> > In XML/SOAP there was a WSDL and some utility converted it to AS
> > ValueObjects.  Other metadata instructed AMF to construct real classes
> > instead of plain objects.  I think there are APIs for that in JSON.parse.
> > I guess I will look into that for the next release.  IMO, if we can't
> > convince folks to use the type system, we lose a major productivity
> > advantage of Royale.  There is always going to be more setup work for
> > Royale. You can't just copy a file and view it in the browser.  You have
> > to run our compiler first.  We should encourage you to create
> ValueObjects
> > at some point.  My tutorial suggests doing it before creating a
> production
> > version.
> >
> > My 2 cents,
> > -Alex
> >
> > On 2/6/18, 12:51 AM, "Gabe Harbs" <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?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>


-- 

Piotr Zarzycki

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

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