flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kessler CTR Mark J" <mark.kessler....@usmc.mil>
Subject RE: [FlexJS] Handling chrome elements
Date Mon, 29 Jul 2013 17:49:54 GMT
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.


-----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.


-----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.



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:
>>Search for '@implements'. It has a short but sweet example.
>>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
>>>>> some compiler code expects to list interfaces in an $implements
>>>>> 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

View raw message