flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Tynjala <joshtynj...@gmail.com>
Subject Re: Variable Renaming (was Re: [Falcon] Proposal for new ActionScript language feature: Optionally rename an import)
Date Wed, 05 Oct 2016 17:04:53 GMT
This seems like a reasonable enough workaround. I really wish GCC weren't
always giving us so many issues. I know many of them are "by design", but
it gets frustrating very quickly.

- Josh

On Wed, Oct 5, 2016 at 9:26 AM, Alex Harui <aharui@adobe.com> wrote:

> So I replaced the @expose usage with @export on Accessors and looked into
> why things don't work when you do that.  It probably is a bug in GCC, but
> I saw an article where GCC developers say that all static definitions are
> considered separate "globals" and not properties of something.  It is an
> interesting philosophy: that statics are just groupings of global
> variables.  Thus I think it is not obvious to GCC that a property defined
> in the Object.defineProperty structure is the same one being referenced by
> other code.  I don't see any annotations we can use to connect the
> defineProperty info to the class definition.
> In related GCC issues, the GCC authors recommend using obj['someProp']
> instead of @export.  There as also another article about how property
> names in Object.defineProperty aren't going to get renamed anyway since
> they are referenced as strings or as keys in the Object.defineProperties
> structure.  So, I've tested out a change to the compiler where any access
> to a static accessor (and only static accessors since instance accessors
> don't have this problem) will be done via obj['someProp'] instead of
> obj.someProp. Yes, that makes the code a bit uglier, but it seems to solve
> this problem.
> That's actually a nice advantage of having a compiler.  We can write our
> code using obj.someProp and the compiler can output something else more
> suitable for GCC.
> Anyway, I wanted to see if anyone objects to this change before I push it.
>  I'm about to start to propagate this change through the unit tests before
> committing.
> Thoughts?
> -Alex
> On 10/3/16, 10:58 PM, "Alex Harui" <aharui@adobe.com> wrote:
> >I pushed changes to generate exportSymbol/exportProperty for certain
> >metadata names.  It fixed the ReflectionTests in GenericTests.
> >
> >I also modified ObservedBugs so that it wouldn't get optimized away.  IMO,
> >folks will just have to realize that certain patterns can be optimized
> >away.  It might be possible to use the @throws jsdoc annotation as well,
> >but I'll leave that for someone else to try.
> >
> >Next up, undo the @expose for accessors and see if there is an alternative
> >solution.
> >
> >-Alex
> >
> >On 10/3/16, 11:07 AM, "Alex Harui" <aharui@adobe.com> wrote:
> >
> >>
> >>
> >>On 10/3/16, 10:51 AM, "Greg Dove" <greg.dove@gmail.com> wrote:
> >>
> >>>That sounds great Alex. Good sleuthing. As keep as3 metadata provides
> >>>for
> >>>specific metadata don't  you think this could be default for the class
> >>>members with specific kept metadata? Given that the only reason for
> >>>keeping
> >>>it would be for reflection, I mean? I will be happy with the option here
> >>>no
> >>>matter how it is implemented though. Thanks!
> >>
> >>Not sure I understood what you meant.
> >>
> >>The default set of keep-as3-metadata includes things like [Bindable] and
> >>I
> >>think we want to allow unused [Bindable] properties to be removed by
> >>default.  I think the set of keep-code-with-metadata we ship could be
> >>empty or include some FlexUnit metadata.
> >>
> >>In trying to implement this, there is an interesting issue.  If we
> >>process
> >>keep-code-with-metadata in COMPJSC when cross-compiling a library, then
> >>you might end up with exportProperty calls in the .JS files and later
> >>when
> >>you use that library in building an app, we have to decide whether the
> >>keep-code-with-metadata assigned to the MXMLJSC run should also apply to
> >>the JS files it is linking to.  If "yes", then we need to keep around
> >>data
> >>about why an exportProperty is in a JS file from COMPJSC so we can prune
> >>stuff out.  Or we have MXMLJSC, but not COMPJSC, scan all .JS files, even
> >>from the SWCs, as the app is being prepared to be shoveled into GCC.
> >>That
> >>would also require keeping some easy-to-understand data in each .JS file
> >>so we don't have to parse the ReflectionData.
> >>
> >>If we say "no", the keep-code-with-metadata only gets processed at
> >>transpile-time, then the implementation is simpler.  I'm going to try the
> >>"no' approach first.
> >>
> >>-Alex
> >>
> >

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