rfc:object_cast_to_types

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
rfc:object_cast_to_types [2012/03/04 01:21]
ircmaxell created
rfc:object_cast_to_types [2017/09/22 13:28] (current)
Line 1: Line 1:
 ===== Request for Comments: Scalar Type Casting Magic Methods ===== ===== Request for Comments: Scalar Type Casting Magic Methods =====
-  * Version: 0.1+  * Version: 0.2
   * Date: 2012-03-03   * Date: 2012-03-03
   * Author: Anthony Ferrara <​ircmaxell@php.net>​   * Author: Anthony Ferrara <​ircmaxell@php.net>​
-  * Status: In Draft+  ​* Maintainer: Matiss Treinis <​mrtreinis@gmail.com>​ 
 +  ​* Status: In Draft (Inactive)
   * Patch: https://​gist.github.com/​1966809   * Patch: https://​gist.github.com/​1966809
  
 ===== Introduction ===== ===== Introduction =====
  
-Currently, the Zend Engine exposes several methods to PECL extensions and internal classes to control how internal objects behave when casting to primitives. ​ The two methods used in this RFC are specifically ''​cast_object()''​ and ''​get()''​ .  This proposal is to expose those two methods as a series of new magic methods to allow user classes to hook into this functionality more completely.+Currently, the Zend Engine exposes several methods to PECL extensions and internal classes to control how internal objects behave when casting to primitives. ​ The two methods used in this RFC are specifically ''​cast_object()''​ and ''​get()''​ .  This proposal is to expose those two methods as a series of new magic methods to allow user classes to hook into this functionality more completely.
  
 ===== Use Cases ===== ===== Use Cases =====
Line 18: Line 19:
    * 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)    * 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 which are not passed by reference.    * 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 which are not passed by reference.
 +   * Allows for objects to carry a Boolean state (to be truthy and falsy)
  
 ===== Implementation ===== ===== Implementation =====
Line 25: Line 27:
 This RFC and patch introduces 4 new magic methods: This RFC and patch introduces 4 new magic methods:
  
- * ''​__toInt()''​ - Called when casting an object explicitly to an integer (or passing it to an internal function which expects an integer) +  ​* ''​_ _toInt()''​ - Called when casting an object explicitly to an integer (or passing it to an internal function which expects an integer) 
- * ''​__toFloat()''​ - Called when casting an object explicitly to a float (or passing it to an internal function which expects a float) +  * ''​_ _toFloat()''​ - Called when casting an object explicitly to a float (or passing it to an internal function which expects a float) 
- * ''​__toArray()''​ - Called when casting an object explicitly to an array (or passing it to an internal function which expects an array) +  * ''​_ _toArray()''​ - Called when casting an object explicitly to an array (or passing it to an internal function which expects an array) 
- * ''​__toScalar()''​ - Called when using an object in an implicit scalar scope without type information (for example: ''​$obj + 1''​).+  * ''​_ _toScalar()''​ - Called when using an object in an implicit scalar scope without type information (for example: ''​$obj + 1''​). 
 +  * ''​_ _toBool()''​ - Called when casting an object explicitly to a boolean (or passing it to an internal function which expects a boolean)
  
 ==== Handler Behavior ==== ==== Handler Behavior ====
  
-When the cast_object handler is called, the type parameter is switched against to determine which magic method to call.  The four possibilities include ''​__toInt()'',​ ''​__toFloat()'',​ ''​__toArray()''​ and ''​__toString()''​.+When the cast_object handler is called, the type parameter is switched against to determine which magic method to call.  The four possibilities include ''​toInt()'',​ ''​toFloat()'',​ ''​toArray()'',​ ''​toString()''​ and ''​toBool()''​.
  
-When the get handler is called, the ''​__toScalar()''​ method is invoked. ​ This would indicate that the cast is to a scalar, but the type is up to the class to determine. ​ This is called when a primitive type is needed, but not a specific one.  So the normal math operators trigger a get call: (+, -, *, /), in addition to compound operators (++, +=, &=, |=, etc).+When the get handler is called, the ''​toScalar()''​ method is invoked. ​ This would indicate that the cast is to a scalar, but the type is up to the class to determine. ​ This is called when a primitive type is needed, but not a specific one.  So the normal math operators trigger a get call: (+, -, *, /), in addition to compound operators (++, +=, &=, |=, etc).
  
 ==== Example Triggers ==== ==== Example Triggers ====
Line 45: Line 48:
    ​(array) $obj; // triggers __toArray()    ​(array) $obj; // triggers __toArray()
    ​array_keys($obj);​ // triggers __toArray()    ​array_keys($obj);​ // triggers __toArray()
 +   ​(bool) $obj; // triggers __toBool()
  
 ==== Backwards Compatibility Breaks ==== ==== Backwards Compatibility Breaks ====
Line 56: Line 60:
 The normal casting logic does not make a distinction between how casts happen with references. ​ So this patch does not attempt to make a distinction there. ​ However, when an internal function accepts a typed parameter by reference, if the magic cast method is defined on the passed in object, an error is raised as the cast cannot be performed because of the reference. The normal casting logic does not make a distinction between how casts happen with references. ​ So this patch does not attempt to make a distinction there. ​ However, when an internal function accepts a typed parameter by reference, if the magic cast method is defined on the passed in object, an error is raised as the cast cannot be performed because of the reference.
  
-This means that an object implementing ​__toArray ​cannot be passed directly to ''​sort()'',​ as that would cause the object to be destroyed. ​ So, to prevent data loss, references are prevented from automated casting.+This means that an object implementing ​''​toArray'' ​cannot be passed directly to ''​sort()'',​ as that would cause the object to be destroyed. ​ So, to prevent data loss, references are prevented from automated casting. 
 + 
 +===== Todo ===== 
 + 
 +  * Patch could use an update. 
 +  * How could and will this interact with comparison and control structures like, ''​if($obj)''​ ?
  
 ===== Further reading ===== ===== Further reading =====
Line 65: Line 74:
   * https://​wiki.php.net/​internals/​engine/​objects#​set   * https://​wiki.php.net/​internals/​engine/​objects#​set
   * https://​wiki.php.net/​internals/​engine/​objects#​cast_object   * https://​wiki.php.net/​internals/​engine/​objects#​cast_object
- 
rfc/object_cast_to_types.1330824103.txt.gz · Last modified: 2017/09/22 13:28 (external edit)