Re: Crux Branch

2019-07-11 Thread Greg Dove
Just a quick update...

I just fixed the ant builds for the 3 simple crux examples in the branch,
which were not working yet.

There will continue to be improvements and fixes over time, but I actually
think it's at a state where it could be merged into develop. Unless there
is a reason not to, I plan to do this by start of next week.
This should not impact anyone else because it is something new, there are
no changes to anything already present.

In terms of the name as 'Crux', so far I had feedback from one person to
give the naming some more thought, mainly because of the possibility for
name conflicts with other libraries.
Carlos suggested to me that we should always use 'Apache Royale Crux' in
terms of a general reference or to introduce it for the first time, and
then (iirc) 'Crux' by itself only in a very clear Apache Royale context,
which avoids naming conflicts. As I understand it, this type of issue is
similar to some other things from the past.

So far I don't see anything holding back a merge. But please let me know if
there is anything else.

Thanks,
-Greg



On Sat, Jul 6, 2019 at 3:35 AM Josh Tynjala 
wrote:

> Interesting! I didn't know that the capture phase worked for non-bubbling
> events. Good to know. Thanks for looking into it and sharing your findings,
> Greg.
>
> - Josh
>
>
> On Thu, Jul 4, 2019, 11:12 PM Greg Dove  wrote:
>
> > Hi Josh,
> >
> > For the addedToStage stuff:
> > You made me look! Swiz does not actually use the ADDED event, it
> definitely
> > does use ADDED_TO_STAGE by default, but you're absolutely right, this
> does
> > not bubble.
> >
> > I did not pay too much attention to the 'bubbling' side of things
> because I
> > could see it working in flash and just assumed that's what was happening.
> > But it is actually being listened to as a capture phase event. And that
> > does give the same outward impression (without looking too closely) as if
> > it were bubbling in this case.
> >
> > I even resorted to a quick test in Adobe Animate to verify:
> >
> > import flash.display.Sprite;
> > import flash.events.Event;
> >
> > var sprite:Sprite = new Sprite();
> > sprite.name ='1';
> > function onAdded(event:Event):void{
> > trace('added' ,event.target.name)
> > }
> > function onRemoved(event:Event):void{
> > trace('removed' ,event.target.name)
> > }
> >
> > sprite.addEventListener(Event.ADDED_TO_STAGE, onAdded, true);
> > sprite.addEventListener(Event.REMOVED_FROM_STAGE, onRemoved, true);
> >
> > var sprite2:Sprite = new Sprite();
> > sprite2.name = '2'
> >
> > var sprite3:Sprite = new Sprite();
> > sprite3.name = '3'
> >
> > addChild(sprite);
> > sprite.addChild(sprite2)
> >
> >
> > sprite2.addChild(sprite3);
> >
> > //remove the child tree
> > sprite.removeChild(sprite2)
> >
> > /*
> > trace output:
> > added 2
> > added 3
> > removed 2
> > removed 3
> > */
> >
> > So I updated the stage events emulator to support this.
> 'removedFromStage'
> > now also works in capture phase on the strand that the bead is on for
> child
> > event targets that were removed.
> > In terms of the names of the events... that is quite easy to change. But
> > whatever we decide on, I just need to add as a  COMPILE::JS variation to
> > the 'default' setupEventType/teardownEventType in the Config class for
> Crux
> > to account for what would now be a difference between SWF and JS (which
> is
> > fine by me, I only started with the same names by trying to match how
> > things worked in swf as they were). So far it does work the same between
> > swf and js builds, although there is only one simple example that builds
> > for both which I have tested with.
> >
> > In terms of the name of the bead, also that can be whatever people think
> > makes sense. I put JS in the name because one of the builds works for
> both
> > swf and js. And seeing that a bead is for JS only is maybe helpful to
> > know.. although I have always wondered whether it would make sense to
> have
> > compiler switches in mxml - some sort of 'transparent' enclosing tag
> > similar to how a COMPILE::JS {  code here } compile block works in
> > actionscript. I don't know it that makes sense something like that
> > could mean that the swf build does not get the unnecessary bead (which
> does
> > nothing in swf anyway)
> >
> > Thanks heaps for the prompts on these things.
> >
> >
> > -Greg
> >
> >
> > On Fri, Jul 5, 2019 at 5:49 AM Carlos Rovira 
> > wrote:
> >
> > > Hi Andrew,
> > >
> > > good point! That's without doubt another new point to bring to :
> > >
> > > - Royale-docs: We can follow most of the documentation available here
> [1]
> > > - Examples: In this case I don't see a Tour app since the use cases are
> > > very direct and can be exposed in few examples.
> > > Greg already provide 3 examples that shows all the things currently
> > > developed here [2]. I think we'll need to do soon a blog example
> > > covering Crux too that could be one of those or a new one. For example
> > TODO
> > > List example would be a 

Re: AMF and class aliases

2019-07-11 Thread Greg Dove
Yes, it should just work. There is at least one working example in the
examples set, and it should work with CommandMessage etc, without any of
the tweaks that you mentioned.

Carlos is using amf extensively and it is currently in use in a production
app.

Let me know if you see any bugs.

cheers,
Greg



On Fri, Jul 12, 2019 at 10:31 AM Frost, Andrew 
wrote:

> Oh it's that simple!
>
> Yes I just took a look, that does appear to go through it all and set
> everything up...
>
> Thank you!  that saved us a bit of effort trying to update the compiler ;-)
>
>
>
>
> -Original Message-
> From: Greg Dove 
> Sent: 11 July 2019 23:27
> To: dev@royale.apache.org
> Subject: [EXTERNAL] Re: AMF and class aliases
>
> Hi Andrew,
> 'but I can't see anywhere that this list is accessed/used.'
>
> I think you need ClassAliasBead on your Application level, which will
> process all the definitions.
>
>
>
>
>
>
> On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew 
> wrote:
>
> > Hi all
> >
> > We're trying to get a connection to work from our Royale-based code to
> > a LiveCycle back-end, and having to debug why the AMF message is
> > different between the Flex version and the Royale version (and trying
> > to work out why the server is rejecting our initial ping message..)
> >
> > One thing that's cropped up is that Flex embeds the name of the class
> > - or rather, the alias of this - when it writes the object:
> > [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
> >
> > In Royale, this capability exists in the
> > AMFBinaryData.writeObjectVariant() method where it's using the
> > "localTraits", and we have:
> > var alias:String = classInfo.alias;//
> > getAliasByClass(instance.constructor
> > as Class); //<- @todo possible optimization: registerClassAlias
> > implementation stores in the classInfo Object, access directly
> >
> > The commented-out code does exactly what the new code does, which is
> > that it accesses the ROYALE_CLASS_INFO structure:
> > var classInfo:Object =
> > instance.ROYALE_CLASS_INFO; so to make this work, we've added an extra
> > section at the end of the ROYALE_CLASS_INFO for the CommandMessage (in
> > the generated JavaScript, so this is not a proper solution!):
> >
> > mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO = {
> > names: [{ name: 'CommandMessage', qName:
> > 'mx.messaging.messages.CommandMessage', kind: 'class' }] , alias:
> > 'flex.messaging.messages.CommandMessage' };
> >
> >
> > Interestingly, the compiler looks at all the [RemoteClass(alias="")]
> > tags, and outputs a list of these in the main application's .js file:
> > TestBackend.prototype.info = function() {
> >   return { "mixins": [mx.messaging.config.LoaderConfig,
> > mx.styles.StyleManagerImpl],
> > "remoteClassAliases": {"mx.messaging.messages.CommandMessage":
> > "flex.messaging.messages.CommandMessage", "org.apache.royale.net
> .remoting.messages.ActionMessage":
> > "flex.messaging.io.amf.ActionMessage", ... etc },
> > "compiledLocales": ["en_US"]}};
> >
> > but I can't see anywhere that this list is accessed/used.
> >
> >
> > So it looks to me like there's a discrepancy between how the compiler
> > is trying to make this work, and how the framework is expecting it to
> > be set up by the compiler. I was wondering if anyone know what had
> > been going on here and whether we should go for one way or another ..
> > and by preference I think, getting the compiler to add the alias
> > directly into the ROYALE_CLASS_INFO as that seems to be a better way of
> doing it I think..?
> >
> >
> > thanks
> >
> >Andrew
> >
> > p.s. we've had a few other issues with the AMF format, e.g. using
> > 'unknown length' and having this as +1 rather than -1; plus a single
> > message was being packaged as an array, whereas Flex/Flash Player
> > doesn't do that.. I'm wondering whether anyone has a problem if we try
> > to make the AMF messages generated from a Royale app to be as similar
> > as possible to how the Flash Player does it..?!
> >
> >
>


Re: AMF and class aliases

2019-07-11 Thread Frost, Andrew
Oh it's that simple!

Yes I just took a look, that does appear to go through it all and set 
everything up...

Thank you!  that saved us a bit of effort trying to update the compiler ;-)




-Original Message-
From: Greg Dove  
Sent: 11 July 2019 23:27
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: AMF and class aliases

Hi Andrew,
'but I can't see anywhere that this list is accessed/used.'

I think you need ClassAliasBead on your Application level, which will process 
all the definitions.






On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew 
wrote:

> Hi all
>
> We're trying to get a connection to work from our Royale-based code to 
> a LiveCycle back-end, and having to debug why the AMF message is 
> different between the Flex version and the Royale version (and trying 
> to work out why the server is rejecting our initial ping message..)
>
> One thing that's cropped up is that Flex embeds the name of the class 
> - or rather, the alias of this - when it writes the object:
> [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
>
> In Royale, this capability exists in the
> AMFBinaryData.writeObjectVariant() method where it's using the 
> "localTraits", and we have:
> var alias:String = classInfo.alias;// 
> getAliasByClass(instance.constructor
> as Class); //<- @todo possible optimization: registerClassAlias 
> implementation stores in the classInfo Object, access directly
>
> The commented-out code does exactly what the new code does, which is 
> that it accesses the ROYALE_CLASS_INFO structure:
> var classInfo:Object = 
> instance.ROYALE_CLASS_INFO; so to make this work, we've added an extra 
> section at the end of the ROYALE_CLASS_INFO for the CommandMessage (in 
> the generated JavaScript, so this is not a proper solution!):
>
> mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO = {
> names: [{ name: 'CommandMessage', qName:
> 'mx.messaging.messages.CommandMessage', kind: 'class' }] , alias:
> 'flex.messaging.messages.CommandMessage' };
>
>
> Interestingly, the compiler looks at all the [RemoteClass(alias="")] 
> tags, and outputs a list of these in the main application's .js file:
> TestBackend.prototype.info = function() {
>   return { "mixins": [mx.messaging.config.LoaderConfig,
> mx.styles.StyleManagerImpl],
> "remoteClassAliases": {"mx.messaging.messages.CommandMessage":
> "flex.messaging.messages.CommandMessage", 
> "org.apache.royale.net.remoting.messages.ActionMessage":
> "flex.messaging.io.amf.ActionMessage", ... etc },
> "compiledLocales": ["en_US"]}};
>
> but I can't see anywhere that this list is accessed/used.
>
>
> So it looks to me like there's a discrepancy between how the compiler 
> is trying to make this work, and how the framework is expecting it to 
> be set up by the compiler. I was wondering if anyone know what had 
> been going on here and whether we should go for one way or another .. 
> and by preference I think, getting the compiler to add the alias 
> directly into the ROYALE_CLASS_INFO as that seems to be a better way of doing 
> it I think..?
>
>
> thanks
>
>Andrew
>
> p.s. we've had a few other issues with the AMF format, e.g. using 
> 'unknown length' and having this as +1 rather than -1; plus a single 
> message was being packaged as an array, whereas Flex/Flash Player 
> doesn't do that.. I'm wondering whether anyone has a problem if we try 
> to make the AMF messages generated from a Royale app to be as similar 
> as possible to how the Flash Player does it..?!
>
>


Re: AMF and class aliases

2019-07-11 Thread Greg Dove
Hi Andrew,
'but I can't see anywhere that this list is accessed/used.'

I think you need ClassAliasBead on your Application level, which will
process all the definitions.






On Fri, Jul 12, 2019 at 10:22 AM Frost, Andrew 
wrote:

> Hi all
>
> We're trying to get a connection to work from our Royale-based code to a
> LiveCycle back-end, and having to debug why the AMF message is different
> between the Flex version and the Royale version (and trying to work out why
> the server is rejecting our initial ping message..)
>
> One thing that's cropped up is that Flex embeds the name of the class - or
> rather, the alias of this - when it writes the object:
> [RemoteClass(alias="flex.messaging.messages.CommandMessage")]
>
> In Royale, this capability exists in the
> AMFBinaryData.writeObjectVariant() method where it's using the
> "localTraits", and we have:
> var alias:String = classInfo.alias;// getAliasByClass(instance.constructor
> as Class); //<- @todo possible optimization: registerClassAlias
> implementation stores in the classInfo Object, access directly
>
> The commented-out code does exactly what the new code does, which is that
> it accesses the ROYALE_CLASS_INFO structure:
> var classInfo:Object =
> instance.ROYALE_CLASS_INFO;
> so to make this work, we've added an extra section at the end of the
> ROYALE_CLASS_INFO for the CommandMessage (in the generated JavaScript, so
> this is not a proper solution!):
>
> mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO = {
> names: [{ name: 'CommandMessage', qName:
> 'mx.messaging.messages.CommandMessage', kind: 'class' }] , alias:
> 'flex.messaging.messages.CommandMessage' };
>
>
> Interestingly, the compiler looks at all the [RemoteClass(alias="")] tags,
> and outputs a list of these in the main application's .js file:
> TestBackend.prototype.info = function() {
>   return { "mixins": [mx.messaging.config.LoaderConfig,
> mx.styles.StyleManagerImpl],
> "remoteClassAliases": {"mx.messaging.messages.CommandMessage":
> "flex.messaging.messages.CommandMessage", 
> "org.apache.royale.net.remoting.messages.ActionMessage":
> "flex.messaging.io.amf.ActionMessage", ... etc },
> "compiledLocales": ["en_US"]}};
>
> but I can't see anywhere that this list is accessed/used.
>
>
> So it looks to me like there's a discrepancy between how the compiler is
> trying to make this work, and how the framework is expecting it to be set
> up by the compiler. I was wondering if anyone know what had been going on
> here and whether we should go for one way or another .. and by preference I
> think, getting the compiler to add the alias directly into the
> ROYALE_CLASS_INFO as that seems to be a better way of doing it I think..?
>
>
> thanks
>
>Andrew
>
> p.s. we've had a few other issues with the AMF format, e.g. using 'unknown
> length' and having this as +1 rather than -1; plus a single message was
> being packaged as an array, whereas Flex/Flash Player doesn't do that.. I'm
> wondering whether anyone has a problem if we try to make the AMF messages
> generated from a Royale app to be as similar as possible to how the Flash
> Player does it..?!
>
>


AMF and class aliases

2019-07-11 Thread Frost, Andrew
Hi all

We're trying to get a connection to work from our Royale-based code to a 
LiveCycle back-end, and having to debug why the AMF message is different 
between the Flex version and the Royale version (and trying to work out why the 
server is rejecting our initial ping message..)

One thing that's cropped up is that Flex embeds the name of the class - or 
rather, the alias of this - when it writes the object:
[RemoteClass(alias="flex.messaging.messages.CommandMessage")]

In Royale, this capability exists in the AMFBinaryData.writeObjectVariant() 
method where it's using the "localTraits", and we have:
var alias:String = classInfo.alias;// getAliasByClass(instance.constructor as 
Class); //<- @todo possible optimization: registerClassAlias implementation 
stores in the classInfo Object, access directly

The commented-out code does exactly what the new code does, which is that it 
accesses the ROYALE_CLASS_INFO structure:
var classInfo:Object = 
instance.ROYALE_CLASS_INFO;
so to make this work, we've added an extra section at the end of the 
ROYALE_CLASS_INFO for the CommandMessage (in the generated JavaScript, so this 
is not a proper solution!):

mx.messaging.messages.CommandMessage.prototype.ROYALE_CLASS_INFO = { names: [{ 
name: 'CommandMessage', qName: 'mx.messaging.messages.CommandMessage', kind: 
'class' }] , alias: 'flex.messaging.messages.CommandMessage' };


Interestingly, the compiler looks at all the [RemoteClass(alias="")] tags, and 
outputs a list of these in the main application's .js file:
TestBackend.prototype.info = function() {
  return { "mixins": [mx.messaging.config.LoaderConfig, 
mx.styles.StyleManagerImpl],
"remoteClassAliases": {"mx.messaging.messages.CommandMessage": 
"flex.messaging.messages.CommandMessage", 
"org.apache.royale.net.remoting.messages.ActionMessage": 
"flex.messaging.io.amf.ActionMessage", ... etc },
"compiledLocales": ["en_US"]}};

but I can't see anywhere that this list is accessed/used.


So it looks to me like there's a discrepancy between how the compiler is trying 
to make this work, and how the framework is expecting it to be set up by the 
compiler. I was wondering if anyone know what had been going on here and 
whether we should go for one way or another .. and by preference I think, 
getting the compiler to add the alias directly into the ROYALE_CLASS_INFO as 
that seems to be a better way of doing it I think..?


thanks

   Andrew

p.s. we've had a few other issues with the AMF format, e.g. using 'unknown 
length' and having this as +1 rather than -1; plus a single message was being 
packaged as an array, whereas Flex/Flash Player doesn't do that.. I'm wondering 
whether anyone has a problem if we try to make the AMF messages generated from 
a Royale app to be as similar as possible to how the Flash Player does it..?!



Re: Build failed in Jenkins: royale-asjs_jsonly #3219

2019-07-11 Thread Carlos Rovira
Seems they finally add officially Element.animate API [1]

it's the same API I added to missing.js

can I remove that from missing.js? or we need to do some GCC update?

thanks


https://github.com/google/closure-compiler/issues/2134

El mar., 9 jul. 2019 a las 11:02, Yishay Weiss ()
escribió:

> There’s also a closure compiler issue [1]. Maybe we can get some direction
> there.
>
>
>
> [1] https://github.com/google/closure-compiler/issues/2134
>
>
>
> 
> From: Harbs 
> Sent: Tuesday, July 9, 2019 11:58:10 AM
> To: dev@royale.apache.org
> Subject: Re: Build failed in Jenkins: royale-asjs_jsonly #3219
>
> animate is not yet a standard and it doesn’t work in Edge or Safari.
>
> I’m not sure if it’s something we should be adding just yet...
>
> > On Jul 9, 2019, at 11:41 AM, Yishay Weiss 
> wrote:
> >
> > I’m not sure. Looking at the js build [1] I can see the externs file
> being read from that repo, so I’m assuming one of them would need to be
> modified in order for the type to be updated. Maybe Harbs can comment on
> this, as he set up the repo.
> >
> >
> >
> > [1] https://github.com/apache/royale-typedefs/blob/develop/js/build.xml
> >
> >
> >
> > 
> > From: Piotr Zarzycki 
> > Sent: Tuesday, July 9, 2019 11:19:06 AM
> > To: dev@royale.apache.org
> > Subject: Re: Build failed in Jenkins: royale-asjs_jsonly #3219
> >
> > Hi Yishay,
> >
> > Should I add also my stuff to make it work to Royale-Extras ?
> >
> > Thanks,
> > Piotr
> >
> > wt., 9 lip 2019 o 10:14 Yishay Weiss 
> napisał(a):
> >
> >> Hi Carlos,
> >>
> >>
> >>
> >> It looks like [1] this is experimental technology, which is probably why
> >> it’s missing from our typedefs [2]. Theoretically it can be added [2],
> but
> >> I don’t know if this is a good idea if it’s not guaranteed to work in
> every
> >> browser.
> >>
> >>
> >>
> >> Thoughts?
> >>
> >>
> >>
> >>
> >>
> >> [1] https://developer.mozilla.org/en-US/docs/Web/API/Element/animate
> >>
> >> [2]
> >>
> https://github.com/royale-extras/closure-compiler/blob/master/externs/browser/w3c_css.js
> >>
> >>
> >>
> >> 
> >> From: Carlos Rovira 
> >> Sent: Tuesday, July 9, 2019 9:50:44 AM
> >> To: dev@royale.apache.org
> >> Subject: Re: Build failed in Jenkins: royale-asjs_jsonly #3219
> >>
> >> I think the problem is we really don't have "animate" method in our
> Element
> >> JS API. I think yesterday I made some kind of wrong compilation.
> >>
> >> Can we add this?
> >> https://developer.mozilla.org/es/docs/Web/API/Element/animate
> >> If so, where should this be done?
> >>
> >> thanks
> >>
> >>
> >>
> >> El mar., 9 jul. 2019 a las 8:45, Carlos Rovira (<
> carlosrov...@apache.org>)
> >> escribió:
> >>
> >>> Seems this change I did yesterday is failing as well in my daily build.
> >>> How is possible this compiled ok yesterday with Maven? but today is
> >> failing?
> >>> I'll be looking at it this morning
> >>>
> >>> 641725 bytes written to
> >>>
> >>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Jewel/target/Jewel-0.9.6-SNAPSHOT-swf.swc
> >>> in 0,701 seconds
> >>>
> >>> COMPCJSCRoyale
> >>>
> >>>
> >>
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/Jewel/src/main/royale/org/apache/royale/jewel/itemRenderers/TabBarButtonItemRenderer.as(197):
> >>> col: 22 Call to a possibly undefined method animate through a reference
> >>> with static type HTMLSpanElement.
> >>>
> >>>
> >>> indicator_content.animate(
> >>>
> >>>  ^
> >>>
> >>>
> >>> 1.469368519 seconds
> >>>
> >>>
> >>> El mar., 9 jul. 2019 a las 6:20, Apache Royale CI Server (<
> >>> apacheroyal...@gmail.com>) escribió:
> >>>
>  See <
> 
> >>
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/3219/display/redirect
> >
> 
>  --
>  [...truncated 1.71 MB...]
>  [java] [getlocal0, pushscope, newcatch(0), dup, setlocal(5), dup,
>  pushscope, swap, setslot(1), getlex[Qname:
>  e::{PackageInternalNs:"org.apache.royale.events"}], debugline(97),
>  getproperty[Qname: name::{PackageNs:""}],
>  pushstring[stopImmediatePropagation], equals, not, debugline(97),
>  iffalse[org.apache.royale.abc.semantics.Label@543c887 => 71]]
>  [java] visiting block: 0
>  [java] max_scope is now:2
>  [java] scpDepth is now:2
>  [java] block 1
>  [java] [popscope, debugline(100)]
>  [java] visiting block: 1
>  [java] max_scope is now:2
>  [java] scpDepth is now:1
>  [java] block 2
>  [java] [pushfalse, returnvalue]
>  [java] visiting block: 2
>  [java] max_scope is now:2
>  [java] scpDepth is now:1
>  [java] block 3
>  [java] [getlex[Qname:
>  e::{PackageInternalNs:"org.apache.royale.events"}], debugline(98),
> >> throw]
>  [java] visiting block: 3
>  [java] 

Re: Jewel CSS winding up in non-Jewel apps

2019-07-11 Thread Josh Tynjala
I like the idea of checking the layout of the SWC. I'll give that a try.

--
Josh Tynjala
Bowler Hat LLC 


On Wed, Jul 10, 2019 at 11:20 PM Alex Harui 
wrote:

> 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"  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.devdata=02%7C01%7Caharui%40adobe.com%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764667456sdata=DEinUrLNfiRQmsk9kPo9bMXAik2hH2R1h6%2FuhvB2fq4%3Dreserved=0
> >
>
>
> On Tue, Jul 9, 2019 at 8:08 PM Alex Harui 
> 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" 
> 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.devdata=02%7C01%7Caharui%40adobe.com%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764677451sdata=LHJYCc917ygDyZi8%2FKIhiGBVW%2BPP%2B6ear%2Fs%2B8XcYW%2F0%3Dreserved=0
> > >
> >
> >
> > On Tue, Jul 9, 2019 at 4:00 PM Alex Harui
> 
> > 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 

Re: Jewel CSS winding up in non-Jewel apps

2019-07-11 Thread Alex Harui
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"  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 



On Tue, Jul 9, 2019 at 8:08 PM Alex Harui  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"  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.devdata=02%7C01%7Caharui%40adobe.com%7C154be39abc3f4b647f3608d7054ee62b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636983708764677451sdata=LHJYCc917ygDyZi8%2FKIhiGBVW%2BPP%2B6ear%2Fs%2B8XcYW%2F0%3Dreserved=0
> >
>
>
> On Tue, Jul 9, 2019 at 4:00 PM Alex Harui 
> 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