Re: Package, Class and Method renaming

Thanks for working on this! I’m going camping with my family this week, so I’m not sure I’m going to be able to test this until the end of the week or next week. Thanks, Harbs > On Aug 12, 2017, at 7:13 AM, Alex Harui wrote: > > I'm not sure I understand your proposal, but FWIW, I believe I h

Re: Re: Package, Class and Method renaming

Bonjour, En congés jusqu'au 4 septembre, je prendrais connaissance de votre message à mon retour. Cordialement, Vincent/AFTER24

Re: Package, Class and Method renaming

I'm not sure I understand your proposal, but FWIW, I believe I have found one way to control renaming of getters and setters. I just pushed changes that collect property names used by MXML and data binding. Those properties are set as properties on Object.prototype in a custom externs file and th

Re: Package, Class and Method renaming

Is there some way we can declare MXML differently so GCC can know that we’re using properties? Maybe instead of strings we can use object literals with proper references? > On Aug 10, 2017, at 6:39 PM, Alex Harui wrote: > > FWIW, I found out that some of that savings is because when something

Re: Package, Class and Method renaming

FWIW, I found out that some of that savings is because when something no longer has @export, it is eligible for dead code removal. That's sort of good, except that GCC's dead code removal can't detect usage from MXML and data binding so it removed stuff it shouldn't. The main SWCs may have to alw

Re: Package, Class and Method renaming

For kicks I tried modifying the compiler to not emit @export for my code (it still has the @exports for SDK code). The result on code size was more than 50KB smaller AFTER gzipping. That’s a reduction of more than 10%. Pretty significant. That’s without any class renaming. Anyway, it blew up m

Re: Package, Class and Method renaming

I don't think GCC knows how to handle the object literal pattern. It doesn't seem to know about using the object literal for Object.defineProperties. GCC sometimes creates a temp var for foo.prototype. Not quite sure when/why, but the minified output isn't always repeating foo.prototype for ever

Re: Package, Class and Method renaming

I hate to visit this topic again, but I’m not sure I understand why we’re defining members the way we are. There’s two ways to define getters and setters. One is using Object.defineProperties. The second is by using object literals.[1] I believe browser support of the two are the same. Object

Re: Package, Class and Method renaming

I've seen GCC not track renames before. The Object.defineProperty is just a data structure and doesn't add to the set of APIs for a class definition. I just realized that the class names are used by SimpleCSSValuesImpl to determine the type selectors. So if you rename those strings you will have

Re: Package, Class and Method renaming

> On Aug 9, 2017, at 11:56 PM, Alex Harui wrote: > > The change I just made should only be for MXML. But I think I saw that I > never did remove the @export for getters and setters in AS. However, > doing so would probably break MXML setting of those properties. > > I don't think you can tell

Re: Package, Class and Method renaming

The change I just made should only be for MXML. But I think I saw that I never did remove the @export for getters and setters in AS. However, doing so would probably break MXML setting of those properties. I don't think you can tell when compiling a SWC which properties someone is going to use f

Re: Package, Class and Method renaming

I just compiled with the new option and it appears to work. Yay. On the other hand, only functions and variables are being minified. getters and setters (which is a very large percentage of the signature of my code) is not. It looks like that adds the @exports for non-mxml files as well. Can we

Re: Package, Class and Method renaming

Hmm. I thought GCC didn't rename those. Anyway, I added back the @export. See if that works for you and then see if you think there is enough obfuscation. Thanks, -Alex On 8/9/17, 12:45 AM, "Harbs" wrote: >The problem is as follows: > >Taking textInput as an example, the MXML gets compiled i

Re: Package, Class and Method renaming

TextField has already this bead, so there is no need to add it. If TextField look bad once you run app without it - that would be a bug - maybe similar to menu where you had to add UpgradeElement after "beadsAdded". Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in c

Re: Package, Class and Method renaming

It’s used elsewhere in MXML and it works just fine. The whole component which has this subcomponent is added at runtime which is why I think the UpgradeElement bead was necessary. The only issue I ran into was with the renaming when using the new option for leaving out @exports. > On Aug 9, 20

Re: Package, Class and Method renaming

Harbs, Questions out of scope of your problem: 1) Is this whole component is created dynamically ? I mean new MyComponent()? 2) MDL TextField has UpgradeElement and you are adding it in MXML - didn't you get upgrade? Something went wrong? Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -

Re: Package, Class and Method renaming

The problem is as follows: Taking textInput as an example, the MXML gets compiled into the following: textInput: { /** @this {com.printui.view.components.PaletteSlider} */ get: function() { return this.textInput_; }, /** @this {com.printui.view.components.PaletteSlider} */

Re: Package, Class and Method renaming

Here’s a problem I ran into: I have a component which has the following: https://paste.apache.org/cN1T In the script block I have references to disableBead, textInput, etc. The instance correctly has properties of disableBead, textInput, etc., but every reference

Re: Package, Class and Method renaming

I’ll give it a go and see. > On Aug 9, 2017, at 8:31 AM, Alex Harui wrote: > > I don't think getters and setters get renamed because they are keys in the > Object.defineProperties data structure. I'm wondering if that will be > enough obfuscation for you or not. > > -Alex > > On 8/8/17, 10:22

Re: Package, Class and Method renaming

I don't think getters and setters get renamed because they are keys in the Object.defineProperties data structure. I'm wondering if that will be enough obfuscation for you or not. -Alex On 8/8/17, 10:22 PM, "Harbs" wrote: >I have a custom component “A” which implements a DisabledBead in >Actio

Re: Package, Class and Method renaming

I have a custom component “A” which implements a DisabledBead in ActionScript. It has a getter called “enabled”. I have another MXML file “B” which uses the component and specifies enabled=“false”. I’m assuming the “enabled” property in “A” will be renamed without an @export. The mxml in “B” w

Re: Package, Class and Method renaming

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" wrote: >Alex fyi I have wondered about breaking the class strings into literal >concatenation expressions with packa

Re: Package, Class and Method renaming

I just tried DataBindingExample. MyInitialView is essentially a custom component. What are you thinking won't work? -Alex On 8/8/17, 2:30 PM, "Harbs" wrote: >Did you try MXML with custom components? I’m not sure I understand how >that would work. > >> On Aug 9, 2017, at 12:01 AM, Alex Harui

Re: Package, Class and Method renaming

Did you try MXML with custom components? I’m not sure I understand how that would work. > On Aug 9, 2017, at 12:01 AM, Alex Harui wrote: > > 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 > st

Re: Package, Class and Method renaming

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 wrote: > Alex fyi I have wondered about breaking the class s

Re: Package, Class and Method renaming

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,

Re: Package, Class and Method renaming

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. So

Re: Package, Class and Method renaming

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 ov

Re: Package, Class and Method renaming

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 lo

Re: Package, Class and Method renaming

Calling get__ and set__ function instead of accessing properties makes for very ugly output. That's how the original output was before we switched to using object.defineProperties and getters and setters. I'd rather not go back. Simple things like: Foo.someInt++ Become: Foo.set__someInt(Foo.g

Re: Package, Class and Method renaming

> On Aug 7, 2017, at 5:52 PM, Alex Harui wrote: > > GCC has some static flow analysis, so yes, they can detect unused > functions, but I don't think it can detect bracket access to functions any > better than bracket access to properties, both of which are allowed in AS > and JS. Yes. I realize

Re: Package, Class and Method renaming

GCC has some static flow analysis, so yes, they can detect unused functions, but I don't think it can detect bracket access to functions any better than bracket access to properties, both of which are allowed in AS and JS. FalconJX doesn't call GCC on the command line. It uses a Java API. I thin

Re: Package, Class and Method renaming

Yishay came across this post: https://stackoverflow.com/questions/10433716/google-closure-compilers-advanced-optimizations-option I wonder if there’s some way to use the property_map options to

Re: Package, Class and Method renaming

Another case which seems to need exports is any property used in MXML. It seems like the low hanging fruit would be to allow some kind of markup to specify classes which don’t need exports. Rewriting constants to literals is another one which should be pretty easy to solve. > On Aug 7, 2017, a

Re: Package, Class and Method renaming

Dynamic access (aka square bracket access) is used in data binding, but people use it for other things as well. The really hard case involves "string math" where you access something like foo[someValue + "label"]. It is hard to know that "enUSLabel" and "frFRLabel" should not be renamed. And yes,

Re: Package, Class and Method renaming

I’m fuzzy on all the reasons for using @import so much. We’ve had discussions on the topic, but hey were spread out. The reasons that stick in my mind was for bracketed access (needed for binding?) and reflection. Another reason I think that was mentioned was for modules (which we don't’ yet re

Re: Package, Class and Method renaming

It might be more interesting and fruitful to investigate removing @export annotations. How could we determine which variables are being accessed via foo[someProperty] and only keep @export on those properties? You might be able to use a text replacement tool to remove @export and mess around with