Support of for-in statement #241
Conversation
ruben-ayrapetyan
added
normal
parser
| * @return header of constructed strings collection (should be freed with ecma_free_values_collection), | ||
| * or NULL - if there are no properties to enumerate in for-in. | ||
| */ | ||
| static ecma_collection_header_t* |
There was a problem hiding this comment.
static ecma_collection_header_t *
ruben-ayrapetyan
force-pushed
the
for-in_dev
branch
from
f16d12f to
ededc97
Compare
|
Good to me. |
|
Please add a test for function calls in for-in, ex: function a() { var tmp = {a: 1, b: 2,c: 3, d: 4}; return tmp; }
for (var i in a()) { console.log(i);} |
| && 'a' in log | ||
| && 'b' in log | ||
| && 'c' in log | ||
| && 'd' in log); |
There was a problem hiding this comment.
Some tests like
for (a in b in c) {}
for ((a in b);;) { break; }
would be good
ruben-ayrapetyan
force-pushed
the
for-in_dev
branch
from
ededc97 to
b474d0b
Compare
|
@zherczeg, @LaszloLango, thank you for your test cases. I've added them to for-in.js test. Please, check. |
| // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| // See the License for the specific language governing permissions and | ||
| // limitations under the License. | ||
|
|
There was a problem hiding this comment.
The properties are iterated incorrectly with this patch. Take the following js:
var arr = [-1,-2,-3];
for(var i in arr)
{
print(arr[i]);
}This will output:
-3
-2
-1
The correct output would be:
-1
-2
-3
There was a problem hiding this comment.
Is the order somehow specified by ECMA-262 v5?
There was a problem hiding this comment.
Ahh, yeah there is no specification on this. So the order is implementation defined, hopefully there is no such test in the test262 expecting the order.
There was a problem hiding this comment.
Oh by the way, other engines iterates arrays in order.
There was a problem hiding this comment.
Ahh, yeah there is no specification on this. So the order is implementation defined, hopefully there is no such test in the test262 expecting the order.
It seems to me that if some test in test262 asserts conditions that are not required by ECMA-262, then the test is incorrect.
Oh by the way, other engines iterates arrays in order.
We can support this enumeration order also, if it would be necessary.
There was a problem hiding this comment.
As far as I understand there is no 'default' order for iterating over the list of properties. Some engines iterate in order of addition, others enumerate numerical properties first (like in Opera).
So, for now, I don't see the reason to change the behaviour until there will be an issue in test262. Otherwise, I need "recommendation" from trusted source.
BTW, We may ask at test262 community.
ruben-ayrapetyan
force-pushed
the
for-in_dev
branch
from
b474d0b to
738d1f3
Compare
|
@galpeter, pull request is updated. Please, check. |
|
|
||
| ecma_string_t *name_p = ecma_get_string_from_value (name_value); | ||
|
|
||
| if (ecma_op_object_get_property (obj_p, name_p) != NULL) |
There was a problem hiding this comment.
Is the ecma_op_object_get_property (obj_p, name_p) == NULL case possible somehow?
There was a problem hiding this comment.
Yes, properties of iterated object could be deleted.
There was a problem hiding this comment.
True, that case didn't occurred to me. BTW, I didn't see such test case, or did I missed something?
There was a problem hiding this comment.
Yes, you are right. The test case should be added.
There was a problem hiding this comment.
Test case is added.
|
Aside from the 'delete' test case, I've got no other comments, lgtm. |
ruben-ayrapetyan
force-pushed
the
for-in_dev
branch
2 times, most recently
from
be56c3d to
6c8025a
Compare
|
|
…ges. JerryScript-DCO-1.0-Signed-off-by: Ruben Ayrapetyan [email protected]
JerryScript-DCO-1.0-Signed-off-by: Ruben Ayrapetyan [email protected]
JerryScript-DCO-1.0-Signed-off-by: Ruben Ayrapetyan [email protected]
ruben-ayrapetyan
force-pushed
the
for-in_dev
branch
from
6c8025a to
3bee50d
Compare
JerryScript-DCO-1.0-Signed-off-by: Evgeny Gavrin [email protected] JerryScript-DCO-1.0-Signed-off-by: Ruben Ayrapetyan [email protected]
ruben-ayrapetyan
force-pushed
the
for-in_dev
branch
from
3bee50d to
507411f
Compare
Authors: Evgeny Gavrin, Ruben Ayrapetyan
Related issue: #51