I guess that might help with the code minification, but it may be
irrelevant with the longer original strings with something like gzip
compression already.... there are so many levels to this.


On Wed, Aug 9, 2017 at 9:12 AM, 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