Looking on it a second time, I guess you have to test it exists in there for both, so maybe it's a moot issue.
-Mark -----Original Message----- From: Kessler CTR Mark J [mailto:mark.kessler....@usmc.mil] Sent: Monday, July 29, 2013 1:43 PM To: dev@flex.apache.org Subject: RE: [FlexJS] Handling chrome elements I've gotten used to being able to do Type checks with "is". It also stands out as a different format visually. I think the only problem with that change is, the child couldn't be null/undefined. It would have to be able to run that method. Whereas the current "is" can compare the datatype with it being null/undefined. -Mark -----Original Message----- From: Erik de Bruin [mailto:e...@ixsoftware.nl] Sent: Monday, July 29, 2013 12:59 PM To: dev@flex.apache.org Subject: Re: [FlexJS] Handling chrome elements Ah, the "is" issue. We don't seem to be able to get out from under a 'helper' method (or whatever the term-du-jour is for that thing) and a 'storage' property. Personally I like to go from this AS: if (child is IChrome) to this JS: if (child.is(IChrome)) That would make it relatively easy to work with it in the cross compiler. Another possibility is to have a global function, but I don't like that very much. Thoughts? EdB On Mon, Jul 29, 2013 at 4:23 PM, Alex Harui <aha...@adobe.com> wrote: > Thanks for that. I'm more interested in the runtime use of interfaces. > What is the JS output for this AS? > > if (child is IChrome) > > It looked like FalconJS was going to create a $implements object on each > class and "is" code would test against that. What should we do for > FalconJX? > > Thanks, > -Alex > > > On 7/28/13 11:50 PM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: > >>More on how to write the JS side: >> >>https://developers.google.com/closure/compiler/docs/js-for-compiler#tags >> >>Search for '@implements'. It has a short but sweet example. >> >>EdB >> >> >> >>On Mon, Jul 29, 2013 at 8:43 AM, Erik de Bruin <e...@ixsoftware.nl> wrote: >>>>> >Also IChrome (looks like a Marker Interface) could lead to a subtle >>>>> >problem >>>>> >on the JS side. I have not been following the conversation on how >>>>>to deal >>>>> >with Interfaces on the JS side. If we are planning on using 'duck >>>>> >typing', >>>>> >then we could run into issues with empty interfaces. Or am I missing >>>>> >something here? >>>>> I'm not sure what we'll end up doing for interfaces on JS. It looks >>>>>like >>>>> some compiler code expects to list interfaces in an $implements >>>>>property >>>>> object. >>>>> >>>> >>>> Can someone shine some light on this? Erik, Michael? >>> >>> Interfaces on the JS side are implemented for the Closure Compiler >>> using the @interface for declaration and the @implements JSDoc >>> annotation. FalconJx knows about this, so - with caution and testing - >>> you should be able to approach interfaces the same in JS as in AS. >>> >>> Let me know if I can help out with some example code or something. >>> Also, if you run into problems, I can alway crack open FalconJx and >>> create the solution you would like to see. >>> >>> EdB >>> >>> >>> >>> -- >>> Ix Multimedia Software >>> >>> Jan Luykenstraat 27 >>> 3521 VB Utrecht >>> >>> T. 06-51952295 >>> I. www.ixsoftware.nl >> >> >> >>-- >>Ix Multimedia Software >> >>Jan Luykenstraat 27 >>3521 VB Utrecht >> >>T. 06-51952295 >>I. www.ixsoftware.nl > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
