Well, I looked into this and this definitely falls into the category of "how did this ever work?"
The use of [] access is on purpose. When you use [Bindable], everything becomes a getter (and setter if writable) and for statics we have to use [] access to deal with GCC renaming. See this background thread if you're interested [1] The reason it didn't work was that a FlexJS class had an exportSymbol near the end of the file, but other methods and variables earlier in the file with @export where being exported before the class's exportSymbol got called. This meant that the export logic would build up a plain object of the @exports then the exportSymbol would wipe that out by replacing that plain object with a reference to the class. I moved the exportSymbol earlier in the file and things seem to work. But I think this means that any access of static getters never worked before!? -Alex [1] https://lists.apache.org/thread.html/9802158cb9bf3b3737d7841ff950130d8e7a6e 10f563e1775aca3b5b@%3Cdev.flex.apache.org%3E On 7/10/17, 9:22 AM, "Harbs" <harbs.li...@gmail.com> wrote: >Not urgent right now. Once I figured out what the problem was, I removed >the Bindable tag. It was not strictly necessary. > >In my case the public static const was not exported. Not sure why. > >I’m not sure that we always want to export these things either, but >that’s a whole ‘nother discussion that I keep putting off until we’re in >a better place. > >Harbs > >> On Jul 10, 2017, at 6:54 PM, Alex Harui <aha...@adobe.com.INVALID> >>wrote: >> >> How urgent is this? I'm trying to figure out why the compiler did not >> respond properly to bad MXML. >> >> I thought public APIs were all exported so they would survive getting >> renamed. In the minified JS, the code will often access the renamed >> variable, but a tree of objects with properties also gets created. >> >> -Alex >> >> On 7/10/17, 2:12 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> It appears that this is the case with any public static getter. >>> >>> public static function get FOO():String{return “foo”} >>> or >>> public static function get FOO():Foo{return _foo} >>> >>> I don’t see any reason why bracket notation would be needed. Is this a >>> throwback from before we had the get__ functions? >>> >>> Thanks, >>> Harbs >>> >>>> On Jul 9, 2017, at 11:27 PM, Harbs <harbs.li...@gmail.com> wrote: >>>> >>>> I just discovered something: >>>> >>>> Foo.as: >>>> package com.acme.foobaz.model{ >>>> [Bindable]public class Foo{ >>>> static public const BAZ:String = “baz”; >>>> } >>>> } >>>> >>>> In some other class: >>>> >>>> if(baz == Foo.BAZ){//do something} >>>> >>>> compiles to: >>>> if(baz == com.acme.foobaz.model.Foo[“BAZ”]) >>>> >>>> If you remove the [Bindable] meta tag on the Foo class, it compiles >>>>to: >>>> if(baz == com.acme.foobaz.model.Foo.BAZ) >>>> >>>> In the debug build, these two are functionally identical. However, >>>>when >>>> Google minifies the file, it has no way of knowing that Foo.BAZ is >>>>used. >>>> This results in calling (assuming com.acme.foobaz.model.Foo becomes >>>>k) >>>> k.BAZ even though k.BAZ was optimized away and k.BAZ is undefined. >>>> >>>> Why does [Bindable] on a class cause the bracket notation to be used? >>>> >>>> Harbs >>> >> >
