That sounds great Alex. Good sleuthing. As keep as3 metadata provides for specific metadata don't you think this could be default for the class members with specific kept metadata? Given that the only reason for keeping it would be for reflection, I mean? I will be happy with the option here no matter how it is implemented though. Thanks!
-Greg [sent from my phone] On 4/10/2016 4:09 AM, "Alex Harui" <aha...@adobe.com> wrote: > Update: Turns out that FalconJX already calls GCC with > --generate-exports, and methods are being exported in the js-release > version. What it looks like to me is that for the one case I am debugging > (ReflectionTesterTest), the setUpBeforeClass method is removed by GCC dead > code removal since there is no obvious code path that calls it. The test > runner sees that setUpBeforeClass is listed as the [BeforeClass] method > but can't find the method and just assigns undefined as the > beforeClassFunc. The runner then doesn't call any beforeClassFunc so the > test is not set up properly and fails. The runner could detect this > condition and report an error, but fundamentally, we need to keep certain > methods from being removed. > > IOW, using @export doesn't prevent a method from being removed by dead > code removal. From the GCC doc, if we generated our own function calls to > exportSymbol/exportProperty, it would prevent the method from being > removed. So, I am now off to teach FalconJX to generate more > exportSymbol/exportProperty calls (FalconJX already generates one > exportSymbol for the class definition). > > Again, I do not want to generate exportSymbol for every public property. > I think we want to use @export and allow for dead code removal most of the > time. My plan is to add an option similar to -keep-as3-metadata. I am > going to call it -keep-code-with-metadata for now. Any methods annotated > with a metadata name in that list will have an exportSymbol or > exportProperty generated for it. A simpler option is to require folks to > add some sort of @dontremove directive or metadata to their code, but that > would be painful to update existing code bases. > > Thoughts? > -Alex > > On 10/1/16, 10:11 PM, "Alex Harui" <aha...@adobe.com> wrote: > > > > > > >On 10/1/16, 12:37 PM, "Greg Dove" <greg.d...@gmail.com> wrote: > > > >>Sorry I did not have time to read up on this yet. > >> > >>If --generate-exports can somehow restore that naming retention for > >>public > >>static members annotated with '@export' then that will be a great > >>starting > >>point as an option to switch this on or off when needed. > > > >AIUI, the use of @export doesn't do anything until you turn on > >--generate-exports. But then, it export every public API in the entire > >app, which is probably not what you want. > > > >
