Anatol, On Mon, Aug 3, 2015 at 10:38 AM, Anatol Belski <anatol....@belski.net> wrote: > Hi Nicolas, > >> -----Original Message----- >> From: nicolas.gre...@gmail.com [mailto:nicolas.gre...@gmail.com] On Behalf >> Of Nicolas Grekas >> Sent: Monday, August 3, 2015 1:29 PM >> To: Rowan Collins <rowan.coll...@gmail.com> >> Cc: internals@lists.php.net >> Subject: Re: [PHP-DEV] Exposing object handles to userland >> >> > >- more importantly for users, these ids couldn't be compared to >> > >var_dumps'. >> > >> > Why do you need to compare the output of two dump functions? Just add >> > a note to the documentation that these are not the same IDs. >> > >> >> That's not a strong feature, but still, it makes the tool a little bit more >> comfortable to use. >> >> Oh, and an other benefit of the handle is that it gives a rough estimation >> of the >> number of objects created and their instantiation order. When debugging, any >> hints count. >> >> For VarDumper, I don't need spl_objet_id(). As we spotted, the code is >> already >> able to get the number it needs. >> >> Having spl_object_id() is still a feature that is not exposed to userland, >> but that is >> useful as I tried to demonstrate. > > I'd be on the side of creating new function, too, if it's really needed. And > not touching the old one. As mentinod before, maybe some other useful cases > could be addressed like immutable strings. > > But with the object id - still, how are the issues mentioned going to be > handled? > > - handle gets reused within the same script, even in same request. There's no > way to realize an object was garbage collected and completely another one has > the same id.\
Well, one way that's handled is by storing a reference to the object. That way you know it's not collected. Basically, if you need to store something associated with an object's id, also store a reference to the object. This is how it's being done today when people use spl_object_hash() and associated objects (like SplObjectStorage). > - what is done in the case the internal implementation was changed, it'll be > probably hard to emulate but some apps will already depend on it. As long as the number returned is unique, it should be pretty straight forward. The contract isn't that a specific integer is returned, it's that it's a unique integer. So if object allocation changes the order that ids are issued, that shouldn't matter. And in practice we've seen that with a few of the changes in 7. A few internal tests may fail because they depend on the detail, but that's because they are bad tests, not the functionality changed. > Maybe just incrementing a static variable were simple enough :) But IMHO > these points need to be addressed prior the implementation. Maybe it's even > not reliable enough to rely on the internal implementation. The problem here is that PHP is used by long-running processes as well. Imagine a server that runs for weeks. It could over the course of that time allocate trillions of objects. But since the handle is 32 bit (a signed int actually, which sounds wrong: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_objects_API.h#43 ), you can only have 2 billion objects allocated at one point in time. Even moving to a 64 bit counter, that's better but is it really necessary? You'd need to store the counter value for every single object. Meaning that you add 8 bytes of memory to each object in the system. Would it be a better experience? Perhaps. Is it necessary? Not sure... I support leaving spl_object_hash() as is, and adding a spl_object_id() which is documented similarly and returns an integer for each object. My $0.02 at least Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
