rfc:objkey

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
rfc:objkey [2014/10/22 01:11] stasrfc:objkey [2015/01/07 07:41] stas
Line 1: Line 1:
 ====== PHP RFC: Objects as hash keys ====== ====== PHP RFC: Objects as hash keys ======
-  * Version: 0.9 +  * Version: 1.0 
-  * Date: 2014-10-21 +  * Date: 2014-10-26 
-  * Author: Stas Malyshev (stas@php.net) +  * Author: Stas Malyshev (stas@php.net), krakjoe 
-  * Status: Draft +  * Status: In Voting
   * First Published at: http://wiki.php.net/rfc/objkey   * First Published at: http://wiki.php.net/rfc/objkey
  
Line 12: Line 12:
 In PHP array keys can be only represented as numbers and strings. However, there already are several classes that represent different kinds of numbers (such as GMP objects) and some objects can also represent strings (e.g. Unicode strings) or string-like objects. It would be convenient to be able to use such objects as array keys to. In PHP array keys can be only represented as numbers and strings. However, there already are several classes that represent different kinds of numbers (such as GMP objects) and some objects can also represent strings (e.g. Unicode strings) or string-like objects. It would be convenient to be able to use such objects as array keys to.
  
-It could be achieved as conversion to string, but this is not ideal since object's string representation does not always match object's identity and there may be case where human-readable string may be different from value for the purposes of hashing.  +It could be achieved as conversion to string, but this is not ideal since object's string representation does not always match object's identity and there may be case where human-readable string may be different from value for the purposes of hashing. Also, some object may prefer to produce numeric index. 
  
 ===== Proposal ===== ===== Proposal =====
-Create a new magic method, __hash() which is called when object is supplied as a hash key, and returns string or integer that is used as the hash key.+Create a new magic method, %%__hash()%% which is called when object is supplied as a hash key, and returns string or integer that is used as the hash key.
  
 A number of languages implement the same facility, namely: A number of languages implement the same facility, namely:
   * Java has hashCode() and toString()   * Java has hashCode() and toString()
-  * Python has __str__, __repr__ and __hash__+  * Python has %%__str__, __repr__ and __hash__%%
   *  Ruby has object.hash   *  Ruby has object.hash
  
-===== Backward Incompatible Changes =====+The method should produce a value which is acceptable as a key (not including objects),  
 +otherwise the engine will still produce an illegal offset type error. The objects not having this 
 +method implemented would produce an illegal offset type error when used in hash key position as before. 
 + 
 +<code php> 
 +<?php 
 +class Foo { 
 +    public function __hash() { 
 +        return "Foo"; 
 +    } 
 +
 + 
 +$foo new Foo(); 
 +$test = [ 
 +    $foo => true 
 +]; 
 +</code> 
 + 
 +Inheritance shall work as any other magic method: 
 + 
 +<code php> 
 +<?php 
 +class Foo { 
 +    public function __hash() { 
 +        return "Foo"; 
 +    } 
 +
 + 
 +class Bar extends Foo { 
 +    /* shall use Foo::__hash unless Bar::__hash is implemented */ 
 +
 + 
 +$bar = new Bar(); 
 +$test = [ 
 +    $bar => true 
 +]; 
 +</code> 
 + 
 +Returning a non-scalar shall fail as it did before: 
 + 
 +<code php> 
 +<?php 
 +class Foo { 
 +    public function __hash() { 
 +        return []; 
 +    } 
 +
 + 
 +$foo = new Foo(); 
 +$test = [ 
 +    $foo => true 
 +]; 
 +</code> 
 + 
 +Shall yield: 
 + 
 +<code> 
 +Warning: Illegal offset type in %s on line %d 
 +</code> 
 + 
 +The current behavior of %%__toString%% is unchanged. 
 + 
 +==== Backward Incompatible Changes ===== 
 Should not break anything as we don't allow this now. Should not break anything as we don't allow this now.
  
Line 42: Line 104:
 Since objects are run-time, should not have any effects on opcache. Since objects are run-time, should not have any effects on opcache.
  
-==== New Constants ==== 
- 
-None. 
- 
-==== php.ini Defaults ==== 
- 
-None. 
  
 ===== Open Issues ===== ===== Open Issues =====
  
-???+  - Should SplFixedArray support object indexes? 
 +  - Should SplObjectStorage support calling %%__hash%% for an object if it exists
  
  
-===== Proposed Voting Choices =====+===== Vote =====
  
-New magic method requires 2/3 majority.+New magic method requires 2/3 majority. The vote also includes choice for the name - %%__hash%% or %%__toKey%%. Vote for either is counted as the vote for the proposal
  
-===== Patches and Tests =====+<doodle title="Should we support using objects as keys as described in this proposal?" auth="stas" voteType="single" closed="true"> 
 +   * Yes, via method __hash 
 +   * Yes, via method __toKey 
 +   * No 
 +</doodle>
  
-TBD+The vote runs from December 16, 2014 to the end of day (PDT) January 6, 2015. 
  
 ===== Implementation ===== ===== Implementation =====
  
-TBD+https://github.com/php/php-src/pull/881
  
 ===== References ===== ===== References =====
Line 73: Line 133:
 ===== Rejected Features ===== ===== Rejected Features =====
  
-None+ - Using %%__toString%%  for the key conversion, for the reasons discussed above.  
 + - Supporting the use of objects for string indexes
rfc/objkey.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1