Is the "isNative()" function hooked up to the native keyword or the [native]
metadata?
This is not the gotcha I was trying to remember in my last post, but one
concern that came to mind was that some API that we consider "native" or a
"typedef" for JS in the browser because it is supplied by the browser or a
third-party library may not be provided the same way on other
platforms/runtimes, so there is a danger that if you declare some class or
function as native that someone trying to create an implementation/emulation of
that API on some other platform/runtime will run into trouble.
So maybe we should flip the problem on its head and consider how to identify
classes whose JS output includes goog.provides(). That feels a bit better
because it is specific to JS output. A possible first approximation would
simply be to see if the SWC has a js/out folder and if it does, assume that all
classes from that SWC support goog.provides. Typedef SWCs should not have a
js/out folder and only an externs folder.
HTH,
-Alex
On 7/10/19, 8:54 AM, "Josh Tynjala" <joshtynj...@bowlerhat.dev> wrote:
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764667456&sdata=DEinUrLNfiRQmsk9kPo9bMXAik2hH2R1h6%2FuhvB2fq4%3D&reserved=0>
On Tue, Jul 9, 2019 at 8:08 PM Alex Harui <aha...@adobe.com.invalid> 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" <joshtynj...@bowlerhat.dev> 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%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764677451&sdata=LHJYCc917ygDyZi8%2FKIhiGBVW%2BPP%2B6ear%2Fs%2B8XcYW%2F0%3D&reserved=0
> >
>
>
> On Tue, Jul 9, 2019 at 4:00 PM Alex Harui <aha...@adobe.com.invalid>
> 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" <joshtynj...@bowlerhat.dev>
> 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%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764677451&sdata=LHJYCc917ygDyZi8%2FKIhiGBVW%2BPP%2B6ear%2Fs%2B8XcYW%2F0%3D&reserved=0
> > >
> >
> >
> > On Tue, Jul 9, 2019 at 3:33 PM Alex Harui
> <aha...@adobe.com.invalid>
> > 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" <joshtynj...@bowlerhat.dev>
> > 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%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764677451&sdata=LHJYCc917ygDyZi8%2FKIhiGBVW%2BPP%2B6ear%2Fs%2B8XcYW%2F0%3D&reserved=0
> > > >
> > >
> > >
> > > On Tue, Jul 9, 2019 at 2:35 PM Josh Tynjala <
> > joshtynj...@bowlerhat.dev
> > > >
> > > 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%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764677451&sdata=LHJYCc917ygDyZi8%2FKIhiGBVW%2BPP%2B6ear%2Fs%2B8XcYW%2F0%3D&reserved=0
> > > >
> > > >
> > > >
> > > > On Tue, Jul 9, 2019 at 3:21 AM Harbs <
> harbs.li...@gmail.com>
> > 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
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
