Implement spl_object_id(object $x) : int #2611
Conversation
|
|
||
| ?> | ||
| ===DONE=== | ||
| <?php exit(0); ?> |
There was a problem hiding this comment.
This is not necessary and hides leaks.
There was a problem hiding this comment.
Makes sense, removed. It's fairly common in ext/spl/tests, so I thought it was some sort of convention.
This was based on spl_object_hash.phpt, changing that is out of scope.
|
@sgolemon @remicollet Are you fine with landing this on 7.2 if no objections arise on the internals list in the next few days? |
TysonAndre
force-pushed
the
spl_object_id
branch
2 times, most recently
from
8400815
to
f436d52
Compare
|
Polyfill implementation ready in |
spl_object_id is a new function returning the object handle, as a signed integer. Discussion for this new function is ongoing on php-internals, see https://marc.info/?t=143835274500003&r=1&w=2 The object id is unique for the lifetime of the object. When the object is garbage collected, different objects may & will have the same object id. - This is also the case for the string generated by spl_object_hash It is always possible to cast the object handle to a **signed** zend_long in php 7.2. _zend_object->handle is always of the type `uint32_t`. (zend_long is 32 bits on 32 bit builds, 64 bits on 64 bit builds) As of php 7.0, the object id uniquely identifies the object, there can't be two objects with the same id but different handlers (See the implementation of spl_object_hash) Skip the pointless XORing, as discussed in internals. - It was intended to avoid exposing in-memory addresses. - The object handle is not a memory address. - The output of var_dump() includes the object handle(id) Commit a unit test of spl_object_id Update NEWS
TysonAndre
force-pushed
the
spl_object_id
branch
from
f436d52
to
76844f0
Compare
|
@nikic - This feature has been on the internals thread for a week without any objections, can it get merged? The feature freeze is on July 18th (3 days from now). Sara Golemon responded on the internals thread earlier. https://marc.info/?l=php-internals&m=149977092723549&w=2
The build failure is a spurious timeout of the test suite as a whole on Travis CI. |
|
friendly ping @sgolemon @remicollet |
|
Merged as 5097e2e into PHP-7.2. |
|
Great to see this merged. 🎉 Although quite unfortunate to see this miss another beta window. :/ |
This PR was merged into the 1.5-dev branch. Discussion ---------- [7.2] Add polyfill for spl_object_id() As [discussed on php-internals](https://externals.io/message/99751) and implemented in php/php-src#2611. Implementation [borrowed from VarDumper](https://github.com/symfony/symfony/blob/2.7/src/Symfony/Component/VarDumper/Cloner/VarCloner.php#L300). Commits ------- 06995f5 [7.2] Add polyfill for spl_object_id()
This was implemented in PR php#2611
This was implemented in PR #2611
spl_object_id is a new function returning the object handle,
as a signed integer.
Discussion for this new function is ongoing on php-internals, see
https://marc.info/?t=143835274500003&r=1&w=2
(Subject: Exposing object handles to userland)
The object id is unique for the lifetime of the object.
When the object is garbage collected,
different objects may & will have the same object id.
It is always possible to cast the object handle to a signed zend_long
in php 7.2. _zend_object->handle is always of the type
uint32_t.(zend_long is 32 bits on 32 bit builds, 64 bits on 64 bit builds)
As of php 7.0, the object id uniquely identifies the object,
there can't be two objects with the same id but different handlers
(See the implementation of spl_object_hash)
Skip the pointless XORing, as discussed in internals.
Commit a unit test of spl_object_id
Update NEWS
EDIT: rebased for 7.2.0beta1