Alex fyi I have wondered about breaking the class strings into literal
concatenation expressions with package parts for CLASS_INFO and in the
reflection data. This should end up minifying via closure compiler much
better, I think.


On Wed, Aug 9, 2017 at 9:01 AM, Alex Harui <> wrote:

> So I just pushed a first crack at suppressing most @export statements.
> Set -export-public-symbols=false and many @export statements should go
> away.  The before size of TLFEditTestFlexJS was 813493 bytes.  I
> recompiled TLF without @export symbols and the after size was 679609
> bytes.  And it ran.
> Some things I found were that MXML isn't a problem because the id maps to
> a getter/setter which maps to Object.DefineProperty which takes an object
> structure where the ids are keys so they don't get renamed.  I noticed
> that class names take up a lot of strings because they are used as a
> literal in the FLEXJS_CLASS_INFO and thus never get minified/renamed.
> Anyway, try compiling and running your application code with this option
> set to false and see if it obfuscates things enough or not, and whether
> the result still runs.
> Thanks,
> -Alex
> On 8/7/17, 9:06 AM, "Alex Harui" <> wrote:
> >From the output side, it probably isn't hard, but there is no way succinct
> >way to tell the compiler which classes should use @export or not.  You
> >could annotate the class definitions, but then you can't choose to output
> >@export without changing source.
> >
> >Why do you think we need per-class control over this output?
> >
> >-Alex
> >
> >On 8/7/17, 8:54 AM, "Harbs" <> wrote:
> >
> >>Cool.
> >>
> >>How difficult would it be to allow this on a class-by-class basis?
> >>
> >>> On Aug 7, 2017, at 6:35 PM, Alex Harui <>
> >>>wrote:
> >>>
> >>> First thing I will do, though, is allow turning off @export output on
> >>> entire compiler sessions.  That might allow you to have your text
> >>>engine
> >>> and your application logic more aggressively renamed but not require us
> >>>to
> >>> fix code in other SWCs that might use bracket access.
> >>
> >

Reply via email to