-
Notifications
You must be signed in to change notification settings - Fork 7.8k
Zend: Refactor object property write API #11387
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
base: master
Are you sure you want to change the base?
Conversation
3339dfe
to
ffcaba5
Compare
add_property_stringl(value, "orgtable", (field->org_table ? field->org_table : ""), field->org_table_length); | ||
add_property_stringl(value, "def", (field->def ? field->def : ""), field->def_length); | ||
add_property_stringl(value, "db", (field->db ? field->db : ""), field->db_length); | ||
static void php_add_field_properties(zval *z_object, const MYSQL_FIELD *field) |
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.
This does not look like an improvement 🤷♂️ What's bad about the old API for these cases (except for the name)?
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.
The main issue is that the _str()
variant takes ownership of the zend_string* value.
The other motivation is to be able to possibly use known zend_strings for the property name access.
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.
Transferring ownership can be useful to avoid unnecessary ADDREF
/DELREF
calls. It would be nice if function names indicated this, since it's not possible through the signature. Having variations for zend_string *
names is useful. It being semantically different in terms of refcounting feels weird.
…as a Zend string Also fix type for bool version and add missing zend_string value for static properties.
As those functions effectively did the same thing just with a slightly different signature Except the add_property_str() version unintentionally took ownership of the zend_string and released it Maintain this awkward behaviour for the time being.
Array version usage: https://sourcegraph.com/search?q=context:global+lang:C+lang:C%2B%2B+add_property_array+-file:Zend/zend_API%5C.h&patternType=standard&sm=1&groupBy=repo Results are unrelated. Object version usage: https://sourcegraph.com/search?q=context:global+lang:C+lang:C%2B%2B+add_property_object+-file:Zend/zend_API%5C.h&patternType=standard&sm=1&groupBy=repo Results are unrelated. Reference version: https://sourcegraph.com/search?q=context:global+lang:C+lang:C%2B%2B+add_property_reference+-file:Zend/zend_API%5C.h&patternType=standard&sm=1&groupBy=repo No results.
Each commit is independent and should be reviewed in order.
The motivation for the first commit comes while I was working on #11381, as a lot of C string usage that would be prime candidates to be converted to known Zend strings were used when trying to update a property, which does not have an API to update a property name directly if one already has the name as a Zend string.
Commit number 2 comes from the realisation that we have a duplicated API which is mostly unused, so converted it to use the more standard
zend_update_property_TYPE()
API.Commit number 3 removes some unused APIs which has been cross-checked using https://sourcegraph.com