Hi!
> This is already part of the public API: var_dump and debug_zval_dump do
> expose object IDs to userland. It's just inefficient to get for more
Debug functions are not the part of public API. If you rely on anything
var_dump is producing for your code to work, you risk your code being
broken any time, without warning or any BC consideration.
> Even if its internal implementation is totally different from PHP's,
> HHVM adds an id to every object, just for this requirement: matching
> what PHP exposes to userland.
That's HHVM's decision, however the fact that they need to fake IDs is
not a good thing. Proper code should not depend on such details of
engine implementation.
> I'd more than happy to have an spl_object_id() function btw!
I wouldn't be very happy, because it is wrong design to base userland
PHP code on a detail of an implementation of the engine. That's why
there was a hash and not direct ID - so that the code would not depend
on implementation detail and anything that produces different hash for
different objects would work.
The alternative (stuffing the ID into spl_object_hash) is worse however.
--
Stas Malyshev
smalyshev@gmail.com