Reviving this thread... Peter says he wants to test to see if an object implements an interface at runtime. What mechanism do we want to use?
I don't think we need to make instanceof work, just have some test to call. -Alex On 7/30/13 12:46 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote: >When using interfaces for type checking, there are two 'kinds': at >compilation and at runtime. > >The @interface and @implements annotations are for compile time checking. > >For runtime checking comes in two flavours: 'instanceof' and 'is'. > >Our method of setting up inheritance (goog.inherits) maintains the >inheritance chain, so 'instanceof' works out of the box. > >The work starts with 'is'. We want to story the 'extends' and >'implements' metadata from AS in the JS classes and create a method to >test against that metadata set. I have a pretty good idea on how to >implement such a beast, but it will require some (ha!) tinkering with >the FlexJS JS framework and FalconJx. That will take some time... > >EdB > > > >On Mon, Jul 29, 2013 at 9:17 PM, OmPrakash Muppirala ><bigosma...@gmail.com> wrote: >> On Mon, Jul 29, 2013 at 11:20 AM, Alex Harui <aha...@adobe.com> wrote: >> >>> I think FalconJS was going to generate something like: >>> >>> if (child != undefined && >>> child.$implements["org.apache.flex.core.IChrome"]) >>> >>> Not sure what it was going to do for classes, maybe chase the prototype >>> chain? >>> >>> The other thing that occurred to me about $implements or >>>child.is(IChrome) >>> is that all objects must then have these properties or functions where >>>the >>> global function could work out of a central database that doesn't >>>decorate >>> the classes. >>> >>> I don't have a strong opinion either way right now. >>> >>> -Alex >>> >> >> From all my research on Closure's @implements handling, it seems like >>there >> should be at least one method/member in the @interface. So how will it >> handle 'Marker Interfaces', i.e. interfaces which have no methods. >> >> IChrome - which we have been discussing in the other thread is this >>kind of >> an interface. It is used to just mark an object so it can be used for >>type >> checking. >> >> Is this possible with Closure? Sorry, I have not set up to Closure >> properly on my machine. Can one of you try this out to see if it is >> possible? >> >> Thanks, >> Om >> >> >>> >>> On 7/29/13 10:49 AM, "Kessler CTR Mark J" <mark.kessler....@usmc.mil> >>> wrote: >>> >>> >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 >>> >>> > > > >-- >Ix Multimedia Software > >Jan Luykenstraat 27 >3521 VB Utrecht > >T. 06-51952295 >I. www.ixsoftware.nl
