Interesting.  Feel free to try it and see.

I'm wondering where we use the class strings in FLEXJS_CLASS_INFO.  Maybe
they can be taken out.

-Alex

On 8/8/17, 2:12 PM, "Greg Dove" <greg.d...@gmail.com> wrote:

>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.
>e.g.
>
>'org.'+'apache.'+'flex.'+'events.'+'Event'
>
>
>
>
>On Wed, Aug 9, 2017 at 9:01 AM, Alex Harui <aha...@adobe.com.invalid>
>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" <aha...@adobe.com.INVALID> 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" <harbs.li...@gmail.com> 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 <aha...@adobe.com.INVALID>
>> >>>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