Integrating SPL

Hey, I'd like to talk about merging SPL into the engine, or at least taking some of the core components of SPL and adapting them to the engine, so that the same functionality is available per-default in PHP5. SPL provides a standard set of interfaces, specifically: Iterator: Allows you to override the foreach construct to work on your object. interface spl_forward { function current(); function next(); function has_more(); } class foo implements spl_forward { } $f = new foo; foreach ($f as $e) { } Array spl_array_read allows you to overload reading elements from an array. interface spl_array_read { function exists($key); function get($key); } spl_array_access allows you to overload writes as well as reads: interface spl_array_access implements spl_array_read { function set($value, $index); } The way I look at it, SPL has to important concepts that we should look at integrating in to Zend Engine 2/PHP5: 1) Overloading objects as arrays. This is a crucial feature when interfacing with external sources, like java, or .net, or even a db extension. It allows you to lazy initialize all data coming from an external source, only taking what you need. Further, there is no need to drink the OO kool-aid, in order to take advantage of this feature. 2) The use of interfaces to ascertain whether or not an object supports a given feature set. The usage of interfaces is good for three reasons. First it is much faster than our current method of checking whether a method exists or not. Second it allows us to have coherent method names (no double underscore), without risking any backwards compatibility isues. Thirdly, it makes it more clear that a class is overloaded, and allows you to simply check for overloads. Therefore, when I talk about integrating SPL and PHP, I think the following steps should be taken: 1) "Fix" the object overloading model to allow you to handle array accesses internally. This includes the iterator concept and and array read and write. This portion of the code would be an integral part of the overloading mechanism (no interfaces required). 2) Export and revise the userspace implementation of overloading, using interfaces to define when and how a object is overloaded. I propose something along the lines of (this stuff isn't original, just formalized) :: // Base overload interface, to allow for checks on whether or not a // object is overloaded interface Overloaded { }; // Overloaded_Value overloads the object itself, allowing you to treat // the object as a base type interface Overloaded_Value implements Overloaded { // Called when the object is directly assigned to // @return null function setValue($value); // Called when the object is cast to type a certain type // or kind-of type // valid types are :: // 'boolean' // 'integer' // 'double' // 'number' // 'string' // 'array' // @return value A value of type $type function asType($type); }; // Overloaded_Iterator allows you to overload an object, to allow // foreach () to move over the object interface Overloaded_Iterator implements Overloaded { // Move forward one element in the object // @return null function next(); // Get the value of the current object // @return zval (a PHP value) function current(); // Tells whether or not the object has more data // @return bool function hasMore(); }; // Overloaded properties allows you to overload both property // *and* array accesses. interface Overloaded_Properties implements Overloaded { // Get $property // @return zval (a PHP value) function get($property); // Set $property // @return nothing function set($property, $value); // Check whether or not $property exists // @return bool function exists($property); } // Allow you to overload method calls interface Overloaded_Methods implements Overloaded { // Catch a method call, $name is the name of the method // @return zval (a PHP value) function call($name); }; Thoughts? This should be relatively easy to implement (although I'm not sure on the timing with regards to the beta), and after thinking about it, this just seems like the way to do it. -Sterling PS: 95% of this message is just building on prior art. Zeev and Andi's prior art, and marcus's prior art. All credit to them :)