-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Use zend_is_iterable #3146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use zend_is_iterable #3146
Conversation
LGTM |
I'm not sure what advantage there is of making this change ? |
@krakjoe This was the last check for an |
@@ -2229,7 +2229,7 @@ static xmlNodePtr to_xml_array(encodeTypePtr type, zval *data, int style, xmlNod | |||
return xmlParam; | |||
} | |||
|
|||
if (Z_TYPE_P(data) == IS_OBJECT && instanceof_function(Z_OBJCE_P(data), zend_ce_traversable)) { | |||
if (Z_TYPE_P(data) == IS_OBJECT && zend_is_iterable(data)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it could be replaced by just if (zend_is_iterable(data))
and moving array check (L2290:2455
) to top of this part?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not going to work, since code in this branch requires only an object (zend_is_iterable
will return true for arrays, too).
Edit: changing zend_is_iterable
to not accept all iterables is going to be a bit of a misnomer, also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Closing this PR as performance and check were affected :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tpunt true, but it would fail even if it was an array as the first part of the conditional can never be true at that point, but I do agree we should evaluate each case before changing it, alternatively we can have some macros to cover common usages like the one in question here
No description provided.