Expose zend_reflection_property_set_raw_value, zend_reflection_property_set_raw_value_without_lazy_initialization

[arnaud-lb]

This exposes the functionality of ReflectionProperty::setRawValue() and ReflectionProperty::setRawValueWithoutLazyInitialiation() to C extensions.

Test failure unrelated.

[DanielEScherzer]

Not sure the current interface is the best to expose, e.g. the void *cache_slot[3] parameters are not really documented

What is the issue with having other extensions just call the reflection methods via the normal mechanism for calling class methods?

[nicolas-grekas]

What is the issue with having other extensions just call the reflection methods via the normal mechanism for calling class methods

CPU overhead!

[arnaud-lb]

@DanielEScherzer I've documented the cache_slot parameter in the comment above the declaration of zend_reflection_property_set_raw_value. It is not uncommon to find such cache_slot parameter in the code base, on functions related to property accesses.

If you prefer, I can change the API to something like this:

typedef reflection_object zend_reflection_property;

PHPAPI zend_reflection_property *zend_reflection_property_create(zend_class_entry *ce, zend_string *name);
PHPAPI void zend_reflection_property_set_raw_value(zend_reflection_property *refl_prop, zend_object *object, zval *value);

What is the issue with having other extensions just call the reflection methods via the normal mechanism for calling class methods?

In addition to being faster, this also provides a nicer API. Instantiating objects and calling methods is not straightforward in C.

[Girgias]

The other thing to mention is calling a "PHP" function/method from C AFAIK requires setting up new VM stacks compared to "just" running in a loop. The other thing is that for global functions those can be disabled by an INI setting. (For classes and class methods that's no longer an issue since 8.5 as the disable_class INI setting got removed)

[DanielEScherzer]

can we add a bit more documentation? I assume

• zend_object *object is what object we are setting a property on
• zend_property_info *prop is the property to set
• zval *value is the value to set

What is the unmangled_name here - if it is the same as the property name, why is a separate parameter needed? The unmangled name could already be retrieved from zend_get_unmangled_property_name(prop-> name)

What does the scope represent - since this is reflection, it doesn't matter what the calling scope is, visibility gets bypassed. Is it the class of the object? Then is it already available as object->ce, so why is a separate parameter needed

Internally reflection might pass the unmangled name and the class entry separately because they are already available and for performance, but that shouldn't be required from external callers

[arnaud-lb]

Internally we use intern->ce as the scope, but we don't have intern here. This is why we have to pass it separately. intern->ce can be different than object->ce and prop->ce:

• intern->ce: The class passed as first argument to new ReflectionProperty(), that we use as scope
• prop->ce: The class on which the property is declared (may be a super class)

I agree that the unmangled_name parameter could be removed, but at the same time it's useful purely for performance reasons, since a part of the purpose of this API is performance. The same is true about the prop and cache_slot parameters.

The proposed API is low level, but it still abstracts away a lot of complexity.