It looks like the native keyword is allowed on functions only. You'll get a compiler error if you try to add the native keyword onto a class. After discovering this, I looked at how classes are compiled into playerglobal.swc, and it looks like they have [native] metadata. That could possibly serve the same purpose.
Here are a few options that might work: 1) Modify the compiler to allow the native keyword to be used on classes. 2) Use [native] metadata to detect typedef classes. 3) Check the class for a constructor that has the native keyword (since a constructor is a function, native is allowed there). -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Tue, Jul 9, 2019 at 8:08 PM Alex Harui <[email protected]> wrote: > Good idea. I have this vague memory that there are some other gotchas > around using "native", but give it a try and see what happens. > > -Alex > > On 7/9/19, 4:21 PM, "Josh Tynjala" <[email protected]> wrote: > > You know, I just realized... we should start adding the "native" > modifier > to ActionScript classes in typedef SWCs. Typedef SWCs serve the same > purpose as playerglobal/airglobal SWCs, which are also compiled as > "native". They all define APIs that will be available at run-time and > the > SWC should only be used for checking types and things at compile-time. > > IDefinition has an isNative() method that tells you if a class was > marked > with the "native" keyword. We would use that instead of > library-path/external-library-path to determine whether goog.require() > is > needed for a particular class. This would keep > library-path/external-library-path working as they always have, without > affecting goog.require(). > > I think I actually suggested using the "native" keyword for typedefs a > very > long time ago. I think you said that externc or the JS emitter didn't > handle it properly. Since I wasn't very familiar with the compiler > code at > the time, I didn't think I could fix it, so I dropped the idea. > > This is what was missing. We were ignoring a feature of the language > that > was meant for exactly this situation. > > -- > Josh Tynjala > Bowler Hat LLC < > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cbdb3db4ff29e40f289e908d704c425d7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983112848931274&sdata=OejBnXkhiEnesxpytUFjtQZ6NOCrMR1%2FWK9zhiVqvuw%3D&reserved=0 > > > > > On Tue, Jul 9, 2019 at 4:00 PM Alex Harui <[email protected]> > wrote: > > > Category #1 is when someone intends to combine code from a SWC into > > another SWC to create one mega-swc, maybe to reduce the number of > SWCs or, > > back in the day, to create one RSL instead of two. I don't think > Royale > > should ever need to do this. > > > > Category #2 is the other AS classes from other SWCs you need. As you > > mentioned Jewel.SWC uses Basic org.apache.royale.states.States (from > > Core.swc or Basic.swc). > > > > Category #3 is definitions that are not in Royale code. For SWF > versions > > of SWCs, it is everything in playerglobal/airglobal. So Sprite, > > DisplayObject, other flash.*.* packages. For JS versions of SWCs it > is > > HTMLElement and other stuff in js.swc or other typedefs. > > > > If you are suggesting that somehow the compiler will know that some > SWCs > > on the external-library-path are typedefs vs a framework class from > > Core.swc or Basic.swc, that might be possible, but I don't know how > > efficient that will be (or accurate) to determine that, plus > portions of > > the compiler have a test for "isExternal()" that we'd have to make > sure we > > get right. > > > > That's why I suggest that we add some new option that lists classes > that > > shouldn't be linked into library.swf without marking them > "isExternal()". > > There is already a similar option that does mark classes as > "isExternal()" > > that we might be able to leverage. > > > > HTH, > > -Alex > > > > > > On 7/9/19, 3:43 PM, "Josh Tynjala" <[email protected]> > wrote: > > > > > 3) code that should not be in the output SWC that doesn't > support > > goog.require/goog.provide > > > > Is there anything other than a typedef SWC that could be > classified as > > #3? > > It seems like we have an extra category that doesn't exist in > > practice, but > > we're giving it priority over a category that is more common. > > > > Not just with framework SWCs either. Third-party SWCs that > include > > custom > > components would need to set the framework SWCs on the > > external-library-path too. > > > > -- > > Josh Tynjala > > Bowler Hat LLC < > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cbdb3db4ff29e40f289e908d704c425d7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983112848931274&sdata=OejBnXkhiEnesxpytUFjtQZ6NOCrMR1%2FWK9zhiVqvuw%3D&reserved=0 > > > > > > > > > On Tue, Jul 9, 2019 at 3:33 PM Alex Harui > <[email protected]> > > wrote: > > > > > I'm not sure why Jewel CSS is winding up in non-Jewel apps, > but the > > issue > > > of whether SWC dependencies should be on the library-path or > > > external-library-path isn't so much as a bug (functionality > that > > isn't > > > working as expected) but rather, a problem we've had "forever". > > > > > > With only -library-path and -external-library-path options, > that is > > only > > > two categories to categorize: > > > > > > 1) code from another library you want included in the output > SWC > > > 2) code that should not be in the output SWC but supports > > > goog.require/goog.provide > > > 3) code that should not be in the output SWC that doesn't > support > > > goog.require/goog.provide > > > > > > When we build the framework, we rarely ever want #1. So we've > been > > using > > > -library-path for #2 and -external-library-path to be #3 and > somehow > > got > > > this far by ignoring the fact that code that shouldn't be > duplicated > > in the > > > SWCs are. I think it has been like that "forever", so no idea > why > > it is > > > breaking now unless folks are using the JS versions of the > SWCs more > > these > > > days. > > > > > > I didn't think the duplication was causing problems but since > it > > > apparently is, I think the compiler would need a way to know to > > exclude > > > certain classes from the output SWF. I think there is already > an > > -externs > > > option but that requires listing every class which would be > painful > > to > > > administrate. And I think that might re-categorize the class > as > > being on > > > the -external-library-path which we don't want either. So > maybe a > > new > > > compiler option to exclude all classes from a SWC in the output > > library.swf > > > is best. > > > > > > HTH, > > > -Alex > > > > > > On 7/9/19, 3:06 PM, "Josh Tynjala" <[email protected]> > > wrote: > > > > > > I have confirmed that these SWCs are defined on the > library-path > > in the > > > compile-js-config.xml used to build JewelJS.swc. Instead, > it > > should be > > > using the external-library-path or > js-external-library-path. > > > > > > In compile-swf-config.xml for Jewel.swc, the dependencies > are > > correctly > > > defined on external-library-path so that they aren't > included in > > > Jewel.swc. > > > > > > Unfortunately, my initial attempts to use > external-library-path > > or > > > js-external-library-path are running into issues. I worry > that > > it may > > > be > > > related to this comment in compile-js-config.xml where the > SWCs > > were > > > added > > > to the library-path: > > > > > > <!-- asjscompc won't 'link' these classes in, but will > list their > > > requires > > > if these swcs are on the external-library-path then > their > > requires > > > will not be listed --> > > > > > > I could be wrong, but I interpret this comment to mean that > > > goog.require() > > > is not added if something is on the external-library-path. > That > > sounds > > > like > > > a bug in the compiler, and this was more of a workaround > than the > > > correct > > > way to fix things. > > > > > > -- > > > Josh Tynjala > > > Bowler Hat LLC < > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cbdb3db4ff29e40f289e908d704c425d7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983112848941268&sdata=W32ZsQSlp6yXbypFbx%2B26jenv3stcKDO5iXxvhpyDPM%3D&reserved=0 > > > > > > > > > > > > > On Tue, Jul 9, 2019 at 2:35 PM Josh Tynjala < > > [email protected] > > > > > > > wrote: > > > > > > > It looks like JewelJS.swc includes some classes in the > SWC that > > > probably > > > > shouldn't be there. One example (but there are many > more): > > > > org.apache.royale.states.State. > > > > > > > > These are core classes that should be from dependencies, > and I > > > suspect > > > > that something might be on the library-path instead of > the > > > > external-library-path. Because the compiler found the > class in > > > JewelJS.swc, > > > > it assumes that it needs defaults.css from JewelJS.swc > too. > > > > > > > > To try to reproduce this issue, I created a sample app > that > > uses only > > > > Basic components. I'm seeing that the compiler is trying > to use > > > > defaults.css from Basic, Express, Jewel, and > > MaterialDesignLite. > > > > > > > > I'll take a look at the compiler options for some of the > other > > SWCs > > > to see > > > > if anything catches my eye. > > > > > > > > -- > > > > Josh Tynjala > > > > Bowler Hat LLC < > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7Cbdb3db4ff29e40f289e908d704c425d7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983112848941268&sdata=W32ZsQSlp6yXbypFbx%2B26jenv3stcKDO5iXxvhpyDPM%3D&reserved=0 > > > > > > > > > > > > > > > > On Tue, Jul 9, 2019 at 3:21 AM Harbs < > [email protected]> > > wrote: > > > > > > > >> I have no jewel components in my app, but I’m suddenly > seeing > > TONS > > > of > > > >> jewel css in my app. > > > >> > > > >> Similarly, I’m seeing Basic CSS (such as Button) which > did > > not used > > > to be > > > >> included (and is messing up the visuals in my app). > > > >> > > > >> Has something changed with the logic which includes CSS? > > > >> > > > >> Harbs > > > > > > > > > > > > > > > > > > > > > > > > > >
