-
Notifications
You must be signed in to change notification settings - Fork 7.8k
Implement spl_object_id(object $x) : int #2611
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
||
?> | ||
===DONE=== | ||
<?php exit(0); ?> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not necessary and hides leaks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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? |
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
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. :/ |
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