phalcon/cphalcon — pull request #777 by sjinks (2013-07-04 01:23:31+00:00)
Title: Refactor property related code a bit

Changes:
* `phalcon_clone()`: renamed `destiny` to `destination`
* `phalcon_read_property()`: made it a wrapper around `zend_read_property()` because:
* in case of `!Z_OBJ_HT_P(object)->read_property` `EG(scope)` was not restored;
* `silent` argument was not honored in calls to `Z_OBJ_HT_P(object)->read_property` (the condition should have been `silent ? BP_VAR_IS : BP_VAR_R`)
* `zend_read_property()` does exactly the same as `phalcon_read_property()` — no overhead but ensures compatibility with the future PHP versions
* `phalcon_read_property_zval()`: a wrapper around `phalcon_read_property()`;
* `phalcon_update_property_string()`: a wrapper around `zend_update_property()` with no overhead;
* `phalcon_update_property_zval()` and `phalcon_update_property_zval_zval()`: wrappers around `zend_update_property()`
* `phalcon_update_property_empty_array()`: `phalcon_update_property_zval()` with an empty array

In most cases all overhead is that zend_read/update_property() cannot be inlined into a Phalcon function; however, almost all phalcon_update_property_XXX functions call their zend_update_property_XXX counterparts, thus this probably is not an issue.

The advantage is the smaller code (can have more in L1i cache :-) ) and compatibility with the future PHP versions without #ifdef's