I’m not complaining about the output. I think the work you guys have done with
the compiler is superb. :-)
However, I do think we should strive to get the output as minified as possible
and there’s probably some strategies which we can employ to get the output more
compact.
I’m not totally clear on your reflection and module issues and use cases. Can
you give some examples where there would be problems?
In my #2 below, this is an optimization which should not effect either one of
your cases. It’s simply an alternate pattern for declaring the prototype which
should be more compact. Is there a reason not to use it?
#3 should not be a problem either. As long as the qualified name is declared in
one place, the shortened version could be used elsewhere by clients.
As far as #4 and exports go, I have a few thoughts:
1. We could have meta-tags in the source code which could tell the FalconJX
compiler how to rename packages and classes. Possibly something like this:
[Export(name="a", package="$fx.c")]
public class Application extends ApplicationBase implements IStrand, IParent,
IEventDispatcher
This would export all references to “org.apache.flex.core.Application" as
“$fx.c.a” instead.
2. An optional tag to specify which pieces should be exported (exposed? I’m not
clear on the difference between the two)
Maybe something like this:
To expose the whole class:
[Export(name="a", package="$fx.c”,type=“external")]
public class Application extends ApplicationBase implements IStrand, IParent,
IEventDispatcher
To not expose the whole class:
[Export(name="a", package="$fx.c”,type=“internal")]
public class Application extends ApplicationBase implements IStrand, IParent,
IEventDispatcher
To expose only pieces:
[Export(name="a", package="$fx.c”,type=“mixed")]
public class Application extends ApplicationBase implements IStrand, IParent,
IEventDispatcher
[Export]
public function doSomething()
[Hide]
public function doSomethingElse()
[Export(name=“voodoo")]
public var someImportantData
Maybe there’s better ways to do this, but this might be a way to control how
output gets optimized (and give control over obfuscation as well).
Thoughts?
On Jul 19, 2016, at 4:50 PM, Alex Harui <aha...@adobe.com> wrote:
>>
>> 2. Prototype definitions are not being optimized as much as they could.
>> The pattern is MyClass.prototype.foo = “some value”; for each one. If
>> that’s replaced with MyClass.prototype = {foo:”somevalue”,…} It’ll save
>> “MyClass.prototype” getting written for every property.
>>
>> 3. Static constants are not being optimized as much as they should. I’m
>> not sure what’s responsible for this, but instead of literals or compact
>> variables, it’s using the fully qualified static name every time.
>>
>> 4. Full class paths are not needed. The class paths could easily be
>> shortened to a few unique characters for significant optimization. I just
>> tried a search and replace on a 900KB file, and just replacing the
>> package paths reduced the file size by 20KB.
>
> We have currently chosen to export every public property in our
> cross-compiled output. That is done to support Reflection, and also to
> support independently built modules someday. The optimizer only knows how
> to optimize the total set of sources given to it. If a module developed
> elsewhere gets loaded at runtime and makes a call, it won't know the
> optimized variable used and needs to resolve the "old-fashioned" way. We
> could add new compiler options to get better optimization some day.
>
> HTH,
> -Alex
