rfc:object_keys_in_arrays

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
Last revisionBoth sides next revision
rfc:object_keys_in_arrays [2021/01/08 09:38] – nikicrfc:object_keys_in_arrays [2021/01/08 15:07] – nikic
Line 54: Line 54:
  
 While an extension to support custom object hashing and comparison overloads may be possible in the future, it is very much out of scope of this proposal. ''SplObjectStorage'' can be used to specify a custom hash function. While an extension to support custom object hashing and comparison overloads may be possible in the future, it is very much out of scope of this proposal. ''SplObjectStorage'' can be used to specify a custom hash function.
 +
 +==== Impact on standard library functions ====
 +
 +For most standard library functions the behavior of object keys is straightforward. E.g. ''array_keys()'' still returns all the keys, but they can now also be objects. The following lists some cases where there is some non-trivial behavior to consider:
 +
 +  * ''extract()'': Ignore object keys. Alternatively we could try to convert them to strings, which would most likely throw.
 +  * ''var_dump()'' etc: How should object keys get represented?
 +  * ''serialize()'': The serialization format can easily deal with object keys. However, keys are currently not counted for back references. To preserve proper identity for object keys, while retaining backwards compatibility with the existing format, we need to count object keys only for back references.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 95: Line 103:
 The stored hash value is reduced to 32-bits in order to fit into u2 space. As hash indices are already limited to 32-bits, this is not problematic. The stored hash value is reduced to 32-bits in order to fit into u2 space. As hash indices are already limited to 32-bits, this is not problematic.
  
-The key zval may have type ''IS_LONG'', ''IS_STRING'' or ''IS_OBJECT''. During bucket lookups, object keys can be mostly treated the same way as integer keys, because comparison of objects only requires comparison of the object pointers (due to limitation to object identity semantics).+The key zval may have type ''IS_LONG'', ''IS_STRING'' or ''IS_OBJECT''. During bucket lookups, object keys can be mostly treated the same way as integer keys, because comparison of objects only requires comparison of the object pointers. The hash value for object keys is the object pointer shifted right by the minimum object alignment.
  
-In order to support object keys (and potentially other key types in the future), a new ''zkey'' family of hash functions and macros is added. ''zkey'' functions accept a zval key, which must be of type ''IS_LONG'', ''IS_STRING'' or ''IS_OBJECT''.+In order to support object keys (and potentially other key types in the future), a new ''zkey'' family of hash functions and macros is added. ''zkey'' functions accept a zval key, which must be of type ''IS_LONG'', ''IS_STRING'' or ''IS_OBJECT''. The u2 value of the zval must already be initialized to contain the key hash. These functions are primarily used when taking a key from an existing array, in which case this initialized is already given.
  
 A non-exhaustive list of new functions: A non-exhaustive list of new functions:
Line 110: Line 118:
 ZEND_API zval* ZEND_FASTCALL zend_hash_zkey_find(const HashTable *ht, zval *key); ZEND_API zval* ZEND_FASTCALL zend_hash_zkey_find(const HashTable *ht, zval *key);
 static zend_always_inline zend_bool zend_hash_zkey_exists(const HashTable *ht, zval *key); static zend_always_inline zend_bool zend_hash_zkey_exists(const HashTable *ht, zval *key);
 +static zend_always_inline zval *_zend_hash_zkey_append(HashTable *ht, zval *key, zval *zv);
 </code> </code>
 +
 +**TODO**: It's not clear yet how to handle the case where now u2 initialization is given. Should there be additional functions for that case, or a function to handle the initialization up-front?
  
 Similarly, ''ZKEY'' variants of ''ZEND_HASH_FOREACH'' macros are introduced: Similarly, ''ZKEY'' variants of ''ZEND_HASH_FOREACH'' macros are introduced:
Line 157: Line 168:
  
 The new macros can be polyfilled for older PHP versions, which is also why this introduces new macros rather than modifying existing ones. The new macros can be polyfilled for older PHP versions, which is also why this introduces new macros rather than modifying existing ones.
 +
 +The ''zend_hash_get_current_key(_ex)'' function is removed. Instead, one of the following two functions can be used (where the former already exists on older PHP versions, while the latter is more efficient):
 +
 +<code c>
 +/* This function populates `key` with a copy of the key, or a null zval if exhausted. */
 +ZEND_API void  ZEND_FASTCALL zend_hash_get_current_key_zval_ex(const HashTable *ht, zval *key, HashPosition *pos);
 +
 +/* This function returns the key zval directly, or NULL if exhausted. */
 +ZEND_API zval* ZEND_FASTCALL zend_hash_get_current_zkey(const HashTable *ht, HashPosition *pos); 
 +</code>
 +
 +The ''zend_hash_get_current_key_type(_ex)'' function and the ''HASH_KEY_IS_LONG'', ''HASH_KEY_IS_STRING'' and ''HASH_KEY_NON_EXISTENT'' constants are also removed, and should be replaced by taking the type of the key zval.
  
 ===== Vote ===== ===== Vote =====
rfc/object_keys_in_arrays.txt · Last modified: 2021/01/11 14:22 by nikic

Page Tools