This is an old revision of the document!
Request for Comments: Weak References
- Version: 0.1
- Date: 2012-02-28
- Author: Anthony Ferrara ircmaxell@php.net
- Status: In Draft
Introduction
Currently, the Zend Engine exposes several methods to PECL extensions and internal classes to control how internal objects behave when casting to primitives, and when assigning to the variable that used to hold the object. The three methods are specifically cast_object(), get() and set(). This proposal is to expose those three methods as two magic methods to allow user classes to hook into this functionality.
Use Cases
Scalar Wrapping
One use-case for this functionality is in creating wrapper classes for scalar values. There are several possibilities that this will enable:
- Creating strict-typing functionality with entirely user-land code (having a variable that until unset cannot be assigned to with anything except an integer for example)
- Having object code be compatible with existing scalar-typed code. An example would be SplFixedArray would be enabled to be passed to any function (including internal functions) that expect arrays.
- Creating new semi-primitive types with functional limitations applied. An example would be the ability to create an integer type that is always less than a configured maximum. Another example would be to create a string type that self-prevents invalid characters (by regex, or otherwise)...
- Creating constant (const) variables that can be written to once (on creation), but not again. (this is sort-of not true, since you can still manually unset() the variable, but it would prevent accidental overwriting)
Providing Backwards Compatibility
Quite a few systems depend on primitives to represent data structures. One example is Drupal's form system that uses multi-dimensional arrays to pass data around. This casting functionality would allow an object system with validation to be used to represent the same structure, and when combined with ArrayAccess and Iterator can be used to provide a backwards-compatible API change. The existing array structures would still be exposed if the code uses array functions or assigns an array to the object. But the new functionality would be exposed since the data is still in a literal object.
Proposal and Patch
This RFC proposes two new magic methods to be called when the internal object handlers are invoked:
mixed __castTo(string $type) bool __assign(mixed $newValue)
When the cast_object handler is called, the castTo method is invoked with a string representation of the type to be casted to. The return value is then used as the “casted” value. A proof of concept patch is available here: https://gist.github.com/1929587 (note, this is a POC ONLY, there are issues with it, such as memory leaks). ==== Example ==== <?php class MyInteger { protected $value; public function construct($value = 1) {
$this->value = (int) $value;
}
public function __castTo($type) {
switch ($type) {
case 'integer':
case 'native':
return $this->value;
case 'float':
return (float) $this->value;
case 'string':
return (string) $this->value;
default:
throw new LogicException('Cannot Cast Integer To ' . $type);
}
}
public function __assign($value) {
if (is_numeric($value)) {
$this->value = (int) $value;
}
return false;
}
}
$foo = new MyInteger(1);
$foo = 2 + 2;
// $foo is still an object, with $value = 4
$foo++;
// $foo is still an object, with $value = 5
$foo = floor($foo);
// $foo is still an object, with $value = 5 (since floor causes a cast to float, and then assignment causes a cast back to int)
$foo = array();
// $foo is now an array, since is_numeric fails