¿Cómo funciona ArrayAccess?

Question

He estado leyendo acerca de las interfaces comúnmente utilizadas de PHP desde el SPL, como Iterator, Countable y ArrayAccess. Sin embargo, no entiendo exactamente cómo funcionan.

¿Sus implementaciones modifican la funcionalidad principal de PHP, por ejemplo sobrecargando el operador de matriz []?

He leído también sobre la extensión del operador, que proporciona la capacidad de sobrecargar otros operadores de la misma manera que los idiomas de nivel inferior. Dado que la extensión del operador modifica claramente el núcleo de PHP, me preguntaba si ArrayAccess actúa de la misma manera detrás de las escenas.

Soy un manipulador, por lo tanto, me resulta difícil usar algo sin saber lo que hay debajo del capó.

Answer 1

Las extensiones PHP y PHP se construyen sobre Zend Engine. Exponen la funcionalidad de Zend Engine a user-land (scripts PHP) y añaden características propias, que están expuestas a user-land o a otras extensiones de PHP.

Zend Engine proporciona un modelo de objetos con una forma de acceder a las dimensiones del objeto (la funcionalidad expuesta por ArrayAccess) y un mecanismo de iteración general que se usa para iterar sobre objetos (idem para Iterator). Este modelo de objetos consiste en una cantidad de manejadores que PHP y cualquier extensión pueden reemplazar para un tipo de objeto (el zend object handlers). Sobre su modelo de objeto, el motor Zend implementa un tipo estándar de objetos (los "objetos zend"); cada objeto tiene la estructura de datos zend_object, y cada clase, que es un concepto que la interfaz de objetos de bajo nivel no conoce aparte de proporcionar una forma de recuperarlo, mediante una estructura zend_class_entry).

ArrayAccess en realidad no es una interfaz SPL; está definido en el motor Zend. Los controladores de bajo nivel read_dimension/write_dimension/has_dimension de objetos zend se implementan de tal forma que comprueban si el objeto implementa dicha interfaz y llaman a los métodos respectivos si ese es el caso (ver here).

Iterator tampoco es una interfaz SPL; también está definido en el Zend Engine. En este caso, el soporte para esta interfaz se realiza en un nivel ligeramente superior. Los manejadores de objetos de bajo nivel no saben nada de la iteración de objetos; esto es una propiedad de Zend Objects. La estructura zend_class_entry tiene dos miembros relevantes aquí: el campo iterator_funcs y el campo get_iterator. Estos definen las operaciones y el estado del iterador y cómo crear un nuevo iterador. Para Iterator en particular, cuando una clase se registra con el tiempo de ejecución, se verifica si implementa esa interfaz, y si lo hace, los campos relevantes en la variable zend_class_entry para esa clase se establecen en métodos nativos que enlazan la interfaz de iteración nativa a PHP métodos. Si uno escribe una extensión de PHP, puede optar por escribir un iterador nativo (que implementa los métodos de iteración de forma nativa) o, como en user-land, implementar Iterator y escribir métodos PHP (en este caso, métodos PHP nativos) para las varias operaciones, como la interfaz describe.

La interfaz Countable es la única que en realidad es una interfaz SPL; Zend Engine no sabe nada al respecto. Su funcionalidad se deriva del hecho de que la implementación del count function comprueba su presencia y llama al método count si existe la interfaz.

La extensión de operador funciona en un nivel más bajo.En tiempo de ejecución, escribe directamente en la memoria de Zend Engine y reemplaza los manejadores de los códigos de operación compilados en código PHP (de modo que ahora, por ejemplo, el ZEND_ASSIGN_ADD tiene una nueva implementación nativa, que difiere a alguna función/método PHP que el usuario puede elegir) .