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