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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
