Yes, exactly.
- Josh
On Tue, May 10, 2016 at 3:38 AM, Andy Dufilie
wrote:
> You're right, it is possible, but I think the key word there was "easily."
> :)
>
> Sent from my Android
> On May 9, 2016 23:59, "Alex Harui" wrote:
>
> >
> >
> > On 5/9/16, 1:22 PM, "Josh Tynjala" wrote:
> >
> > >Tha
You're right, it is possible, but I think the key word there was "easily."
:)
Sent from my Android
On May 9, 2016 23:59, "Alex Harui" wrote:
>
>
> On 5/9/16, 1:22 PM, "Josh Tynjala" wrote:
>
> >That's a good call, Andy. You're absolutely right that a for-each loop
> >could also have its own ret
On 5/9/16, 1:22 PM, "Josh Tynjala" wrote:
>That's a good call, Andy. You're absolutely right that a for-each loop
>could also have its own return statements that are meant for the
>surrounding function. With that in mind, I don't think there's a special
>case here that the compiler can easily d
That's a good call, Andy. You're absolutely right that a for-each loop
could also have its own return statements that are meant for the
surrounding function. With that in mind, I don't think there's a special
case here that the compiler can easily detect to optimize. It sounds like
you should simpl
There can also be return statements within loops as well as "break to
label" or "continue to label". It all seems very messy to me and I still
think it should be behind an optimization option. The current
implementation works perfectly and I would prefer the JS output to be
minimally different fr
On 5/9/16, 9:37 AM, "Josh Tynjala" wrote:
>We might be able to figure out how to use Array.some() instead. Return
>false for most iterations of the loop, and then return true when a "break"
>is encountered (and return false when "continue" is encountered).
>Replacing break and continue could be
We might be able to figure out how to use Array.some() instead. Return
false for most iterations of the loop, and then return true when a "break"
is encountered (and return false when "continue" is encountered).
Replacing break and continue could be tricky, though, since they are
handled in a diffe
Rats. Good point…
On May 9, 2016, at 8:12 AM, Alex Harui wrote:
> Isn't tan issue with Array.forEach() that you can't use 'break' to stop
> the loop?
>
> -Alex
>
> On 5/8/16, 3:41 AM, "Harbs" wrote:
>
>> So would this be a workable solution?
>>
>> This:
>>
>> for each(item in object){
>>
Isn't tan issue with Array.forEach() that you can't use 'break' to stop
the loop?
-Alex
On 5/8/16, 3:41 AM, "Harbs" wrote:
>So would this be a workable solution?
>
>This:
>
>for each(item in object){
> item.doSomething();
>}
>
>Would become:
>
>if (!!object.forEach){
> object.forEac
So would this be a workable solution?
This:
for each(item in object){
item.doSomething();
}
Would become:
if (!!object.forEach){
object.forEach(function(item){
item.doSomething();
});
} else {
var foreachiter0_target = object;
for (va
The array forEach() seems like an acceptable alternative. Looking at MDN
[1], forEach is widely supported in browsers. Including IE 9.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach
- Josh
On Sat, May 7, 2016 at 4:32 PM, lizhi wrote:
> 10x slow.
10x slow.
maybe use the arr.forEach.
pls run this code
https://gist.github.com/matrix3d/a9765b94ade3d626ad64d16f28deccae
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/flexjs-foreach-very-slow-tp52571p52880.html
Sent from the Apache Flex Development maili
I agree with Andy. The default behavior should remain syntax sugar on top
of for-in.
- Josh
On Sat, May 7, 2016 at 11:38 AM, Andy Dufilie
wrote:
> If you do make this change it should be an optional compiler argument,
> because this changes the behavior of the code. The following loop should
>
If you do make this change it should be an optional compiler argument,
because this changes the behavior of the code. The following loop should
print 1 and 2, not undefined:
var array = [];
array[2] = 1;
array[4] = 2;
for each (var x in array)
trace(x);
On May 7, 2016 10:18 AM, "Alex Harui"
On 5/7/16, 1:32 AM, "lizhi" wrote:
>must ded the type.
>if(Array){
> for(var i=0;i}else{
> for in
>}
Should be doable. How much faster is it?
Please file a pull request or JIRA so we don't forget this issue.
Thanks,
-Alex
must ded the type.
if(Array){
for(var i=0;ihttp://apache-flex-development.247.n4.nabble.com/flexjs-foreach-very-slow-tp52571p52864.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
I also commented on JIRA with information about a best practice when using
for-in in JavaScript that avoids that issue.
- Josh
On Mon, Apr 25, 2016 at 11:33 AM, Harbs wrote:
> I don’t think I realized that for each can be used for normal Objects in
> ActionScript. I always assumed it was restri
I don’t think I realized that for each can be used for normal Objects in
ActionScript. I always assumed it was restricted to array-like objects to loop
through the indexed values.
Like I mentioned in the JIRA here:
https://issues.apache.org/jira/browse/FLEX-35070 that for-in is not a good
repl
for-each loops are commonly used with string keys too, so I'm guessing
that's why the code gets converted to a for-in loop. That would be fully
compatible with both integer and string keys. I guess if the target is an
Array or Vector, it would be possible to use a for(;;) loop instead. It
could sti
Please add a comment to this JIRA:
https://issues.apache.org/jira/browse/FLEX-35070
On Apr 25, 2016, at 10:37 AM, lizhi wrote:
> i do not konw the best code,but this code fast than now
>
> //slow code
> var foreachiter0_target = this.ss;
> for (var foreachiter0 in foreachiter0_target)
> {
>
20 matches
Mail list logo
