flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: [FlexJS] Handling interfaces
Date Tue, 30 Jul 2013 07:46:40 GMT
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
<bigosmallm@gmail.com> wrote:
> On Mon, Jul 29, 2013 at 11:20 AM, Alex Harui <aharui@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.ctr@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.ctr@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:erik@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 <aharui@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" <erik@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 <erik@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

Mime
View raw message