On 7/29/13 11:56 AM, "OmPrakash Muppirala" wrote:
>>>
>> >The user still needs to keep track of the index length chrome elements
>>and
>> >regular elements.
>> I don't think I'm understanding this.
>>
>
>If I want to add an element as a chrome, I will need to know the number of
>elements already
On Sun, Jul 28, 2013 at 11:24 PM, Alex Harui wrote:
>
>
> On 7/28/13 2:20 AM, "OmPrakash Muppirala" wrote:
> >>
> >> At this point, I'm liking flags better, but I'm still not decided.
> >>
> >>
> >Sounds like a good compromise. Although I am not sure if it solves the
> >issue of index managemen
quot;
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
>T
reas 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"
"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&#
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
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,
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 wrote:
>>> >Also IChrome (looks like a Marker Interface) could lead to a s
>> >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 interfa
On 7/28/13 2:20 AM, "OmPrakash Muppirala" wrote:
>>
>> At this point, I'm liking flags better, but I'm still not decided.
>>
>>
>Sounds like a good compromise. Although I am not sure if it solves the
>issue of index management. I guess it would look like this:
>addElementAt(o:Object, index:int
On Fri, Jul 26, 2013 at 9:34 PM, Alex Harui wrote:
>
>
> On 7/26/13 7:06 PM, "OmPrakash Muppirala" wrote:
>
> >On Fri, Jul 26, 2013 at 6:07 AM, Peter Ent wrote:
> >
> >> I could go either way on this as well. There is one advantage I can
> >>think
> >> of that addChromeElement et al has over th
11 matches
Mail list logo
