# toString() and Object #ID - Thread: https://externals.io/message/30366 - Original archive: https://news-web.php.net/php.internals/30366 - Started by Lars Schultz on 2007-06-29T14:40:28+00:00 - Messages: 40 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/30366.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #30366 — Lars Schultz — 2007-06-29T14:40:28+00:00 URL: https://externals.io/message/30366#30366 Hi there I just tried to switch from 5.1 to 5.2.3 and got thrown off right away by: "Object of class MyObject could not be converted to string" I googled a bit and also read any Messages in the internals list but couldn't find a decisive answer as to wether this will stay this way or not. In the "PHP 5 Bug Summary Report" I found Bug # 40799 "change string conversion behaviour for objects not implementing __toString()" which is still open. I don't want to complain or anything but I'd like to know wether it's feasible to wait for a change in this current, modified, behaviour or if it's going to stay this way. I used the previous behaviour mostly for debugging purposes where I wanted to get a visual (string) handle for any given object, which helps ALOT when trying to figure out wether one has a copy or the original and wether to references point to the same object....(obj1 === obj2 is not always helpful). Is there any other way than casting an object to a string to get an objects #ID? Thanks for your time. Lars --- ## #30367 — Evert | Rooftop — 2007-06-29T14:56:10+00:00 URL: https://externals.io/message/30366#30367 · In reply to: #30366 Hi Lars, In the meanwhile .. check out spl_object_hash Evert Lars Schultz wrote: > Hi there > > I just tried to switch from 5.1 to 5.2.3 and got thrown off right away > by: > "Object of class MyObject could not be converted to string" > > I googled a bit and also read any Messages in the internals list but > couldn't find a decisive answer as to wether this will stay this way > or not. > > In the "PHP 5 Bug Summary Report" I found Bug # 40799 > "change string conversion behaviour for objects not implementing > __toString()" > > which is still open. I don't want to complain or anything but I'd like > to know wether it's feasible to wait for a change in this current, > modified, behaviour or if it's going to stay this way. > > I used the previous behaviour mostly for debugging purposes where I > wanted to get a visual (string) handle for any given object, which > helps ALOT when trying to figure out wether one has a copy or the > original and wether to references point to the same object....(obj1 > === obj2 is not always helpful). Is there any other way than casting > an object to a string to get an objects #ID? > > Thanks for your time. > Lars --- ## #30371 — Stanislav Malyshev — 2007-06-29T21:23:42+00:00 URL: https://externals.io/message/30366#30371 · In reply to: #30366 > always helpful). Is there any other way than casting an object to a > string to get an objects #ID? spl_object_hash? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #30372 — Cristian Rodriguez — 2007-06-29T23:35:57+00:00 URL: https://externals.io/message/30366#30372 · In reply to: #30366 > Hi there > > I just tried to switch from 5.1 to 5.2.3 and got thrown off right away by: > "Object of class MyObject could not be converted to string" > > I googled a bit and also read any Messages in the internals list but > couldn't find a decisive answer as to wether this will stay this way or not. > > > In the "PHP 5 Bug Summary Report" I found Bug # 40799 > "change string conversion behaviour for objects not implementing > __toString()" > > which is still open. I don't want to complain or anything but I'd like > to know wether it's feasible to wait for a change in this current, > modified, behaviour or if it's going to stay this way. The old beahviuor was absolute non-sense.. > always helpful). Is there any other way than casting an object to a > string to get an objects #ID? > use `var_dump()` or spl_object_hash for that. --- ## #30382 — Pavel Shevaev — 2007-07-01T07:24:00+00:00 URL: https://externals.io/message/30366#30382 · In reply to: #30371 > > […] > > spl_object_hash? Guys, excuse my being a little offtopic here, but why not introduce standard "get_object_id" function in PHP6 which could be analogous to "spl_object_hash"? IMHO it's a basic functionality which deserves to be in the core... -- Best regards, Pavel --- ## #30383 — Gwynne Raskind — 2007-07-01T07:27:25+00:00 URL: https://externals.io/message/30366#30383 · In reply to: #30382 > > […] > Guys, excuse my being a little offtopic here, but why not introduce > standard "get_object_id" function in PHP6 which could be analogous to > "spl_object_hash"? IMHO it's a basic functionality which deserves to > be in the core... +1 on PHP_FEALIAS()ing this. -- Gwynne, Daughter of the Code "This whole world is an asylum for the incurable." --- ## #30384 — Sebastian Bergmann — 2007-07-01T08:10:11+00:00 URL: https://externals.io/message/30366#30384 · In reply to: #30382 Pavel Shevaev schrieb: > Guys, excuse my being a little offtopic here, but why not introduce > standard "get_object_id" function in PHP6 which could be analogous to > "spl_object_hash"? IMHO it's a basic functionality which deserves to > be in the core... SPL is "in the core" AFAIAC. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #30385 — Marcus Boerger — 2007-07-01T11:12:43+00:00 URL: https://externals.io/message/30366#30385 · In reply to: #30383 Hello Gwynne, no more unnecessary aliases please. marcus Sunday, July 1, 2007, 9:27:25 AM, you wrote: > > > […] > +1 on PHP_FEALIAS()ing this. > -- Gwynne, Daughter of the Code > "This whole world is an asylum for the incurable." Best regards, Marcus --- ## #30386 — Pavel Shevaev — 2007-07-01T11:42:02+00:00 URL: https://externals.io/message/30366#30386 · In reply to: #30384 > > SPL is "in the core" AFAIAC. I really want to hope it will be in PHP6. Still IMHO get_object_id sounds much better than spl_object_hash and it will be much easier(and more logical) to locate this function in "Class/Object Functions" section of documentation than in SPL... -- Best regards, Pavel --- ## #30387 — Marcus Boerger — 2007-07-01T13:45:38+00:00 URL: https://externals.io/message/30366#30387 · In reply to: #30386 Hello Pavel, technically object id is neither what you get nor what you want. It is not unique and thus not helpfull and we have no intention to ever provide a function to access it. See mail archieve for reference on why we won't. Also the function resides in extension SPL so correctly it is prefixed with 'spl_'. Furthermore it is no engine specific function but an object oriented programming specific one. So SPL indeed is a very good place for it. Lastly the function per design hashes the unique input it gives as we do not want to make it more complex than necessary or give you stuff that leads to missuse. Again see mail archive for why. That said the name appears to be the best option already. marcus Sunday, July 1, 2007, 1:42:02 PM, you wrote: > > […] > I really want to hope it will be in PHP6. Still IMHO get_object_id > sounds much better than spl_object_hash and it will be much easier(and > more logical) to locate this function in "Class/Object Functions" > section of documentation than in SPL... > -- > Best regards, Pavel Best regards, Marcus --- ## #30388 — Pavel Shevaev — 2007-07-01T19:18:19+00:00 URL: https://externals.io/message/30366#30388 · In reply to: #30387 > Again see mail archive for why. That said the name appears to be > the best option already. Oh, yes, you're right spl_object_hash does its job and does it very well, there's really no point rename it(or make an alias) into object_get_id. I should have stated more clear what I think object_get_id could actually be. How about object_get_id being a function returning the very first line of var_dump's output being applied to the object? Let me be a bit more specific, here's an example of var_dump usage: $ php -r "class Foo{};$foo = new Foo();var_dump($foo);" object(Foo)#1 (0) { } What I actually need, not the object hash but simply its unique id. And in this case "object(Foo)#1" would be just fine. How can I get it? The only way AFAIK is to surround var_dump with ob_start/ob_get_contents/ob_end_clean functions and extract this value. The problem with approach is if one has a complex object connected with a graph of other complex objects(with recursive links) var_dump may take a _very_ long time to complete. And this is what object_get_id could do - simply return object id prefixed with the class name. -- Best regards, Pavel --- ## #30389 — Lars Schultz — 2007-07-01T19:38:41+00:00 URL: https://externals.io/message/30366#30389 · In reply to: #30388 > What I actually need, not the object hash but simply its unique id. > And in this case "object(Foo)#1" would be just fine. How can I get it? That was my original Question too;) It's been stated that the automatic cast into a string even if it does not implement the __toString() function was "absolute nonsense"...but it really helped alot when you needed to check for errors quickly and easily. Why make something harder than it has to be. Why not allow the old behaviour as long as the __toString is not implemented? Or rather something like a default implementation which is used autmatically for every class which doesn't implement it itself? public function __toString(){ return 'Object '. get_class($this) .'('. get_object_id($this) .')'; } That'd be nice and no code breakage would result. Isn't that an approach that fits into the PHP philosophy? The new behaviour reminds me of Java's "the more userland-code, the better". --- ## #30390 — Sebastian Bergmann — 2007-07-01T19:50:03+00:00 URL: https://externals.io/message/30366#30390 · In reply to: #30388 Pavel Shevaev schrieb: > What I actually need, not the object hash but simply its unique id. The problem is that there is no such unique id in the current engine. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #30392 — Pavel Shevaev — 2007-07-01T20:01:48+00:00 URL: https://externals.io/message/30366#30392 · In reply to: #30390 > The problem is that there is no such unique id in the current engine. Am I right in my guess that there's only a counter for each object type? Still being not really unique this information could be very useful and enough in many situations. -- Best regards, Pavel --- ## #30391 — Lars Schultz — 2007-07-01T20:23:22+00:00 URL: https://externals.io/message/30366#30391 · In reply to: #30390 > The problem is that there is no such unique id in the current engine. > Okay!;) That's a very good reason, I guess;) Explains a lot. Why not use spl_object_hash instead of the old default behaviour? --- ## #30394 — David — 2007-07-01T21:40:56+00:00 URL: https://externals.io/message/30366#30394 · In reply to: #30392 (accidentally didn't send this to the whole group at first) > Am I right in my guess that there's only a counter for each object > type? Still being not really unique this information could be very > useful and enough in many situations. The "counter" is global, but it's not really a counter. "Object ids" are actually handles (basically indices) into an internal array holding data to all objects currently in memory. Handles are reused when an object is destroyed so that the array could be kept as small as possible. However, if you are comparing the handles of two objects that are known to be currently in memory, if they have the same handle, then they are the same object (i.e. one spot in memory). However, if you stored the handle of the object in another area of memory so that you can check it against other objects later, it's hard to ensure that the results of that comparison is meaningful. Therefore, it's better to use spl_object_hash to actually ensure objects are the same. Internally, the hash is performed on the object handle (what you've been calling the "object id") as well as the internal list of handlers for that object (basically the "type" of the object), so there's reasonable confidence that a unique hash will be generated. It looks like it's independent of the actual properties, etc. of the object. Spl_object_hash is what you guys want. David --- ## #30396 — Stanislav Malyshev — 2007-07-02T04:34:05+00:00 URL: https://externals.io/message/30366#30396 · In reply to: #30392 > Am I right in my guess that there's only a counter for each object > type? Still being not really unique this information could be very > useful and enough in many situations. It's more complicated than that. Basically what uniquely identifies the object is the tuple (handlers, ID) - it's more or less by definition since handlers decide what to do with an object based on ID. Now, if we talk about "pure" PHP objects (i.e. made by regular PHP user-defined classes, no tricks) then the handlers would be the same and the ID is unique. However, extensions can produce their own handlers and their own IDs, and they don't even have to adhere to the concept that (class, ID) should uniquely identify the object. I don't know of extension that creates different handler sets for the same class, but there's nothing in the engine preventing anybody from doing that - though I'm not sure it's that good an idea. So (class, ID) would probably work now, but is not guaranteed to work. Just ID would have good chance to break with some extensions. Yes, spl_object_hash uses the correct tuple - (handlers, ID). -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #30397 — Stanislav Malyshev — 2007-07-02T04:35:22+00:00 URL: https://externals.io/message/30366#30397 · In reply to: #30394 > will be generated. It looks like it's independent of the actual properties, > etc. of the object. Spl_object_hash is what you guys want. Sure, object identity is not related to properties in any way. Same object can have different properties during the lifetime, and different objects can have identical properties. spl_object_hash is unique in the terms of object identity. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #30404 — Pavel Shevaev — 2007-07-02T09:20:03+00:00 URL: https://externals.io/message/30366#30404 · In reply to: #30397 Guys thank you all very much for this detailed explanation! > spl_object_hash is unique in the > terms of object identity. I really don't want to be annoying but from the end user's POV spl_object_hash sounds like a function which returns a hash but not an identity. Any tiny chance it will be available as object_get_id in PHP6? ;) -- Best regards, Pavel --- ## #30407 — Stanislav Malyshev — 2007-07-02T17:43:13+00:00 URL: https://externals.io/message/30366#30407 · In reply to: #30404 > I really don't want to be annoying but from the end user's POV > spl_object_hash sounds like a function which returns a hash but not an > identity. Any tiny chance it will be available as object_get_id in > PHP6? ;) It does give the hash, which is unique for each object. In which form would you expect object_get_id to return object's identity? PHP doesn't have a type of "tuple of C pointer and long integer" ;) -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #30408 — Sebastian Bergmann — 2007-07-02T17:46:58+00:00 URL: https://externals.io/message/30366#30408 · In reply to: #30407 Stanislav Malyshev schrieb: > It does give the hash, which is unique for each object. In which form > would you expect object_get_id to return object's identity? PHP doesn't > have a type of "tuple of C pointer and long integer" ;) We could add a counter that gets incremented for each object that is created and associate that number with the object. Wouldn't that solve the problem (if there is one)? -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 --- ## #30409 — Stanislav Malyshev — 2007-07-02T17:52:03+00:00 URL: https://externals.io/message/30366#30409 · In reply to: #30408 > We could add a counter that gets incremented for each object that is > created and associate that number with the object. Wouldn't that solve > the problem (if there is one)? It would solve it, but it would require modifying each extension dealing with objects in order to register all objects in this global registry and of course it would require adding another value into object structure. I'm not sure having running numeric ID is that important. If you just need to know if two variables are the same object, you have ===. If you need to index by it, you have the hash. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #30410 — David — 2007-07-02T18:16:09+00:00 URL: https://externals.io/message/30366#30410 · In reply to: #30407 (Many apologies for the double e-mail. Ugh, I'm not used to hitting Reply To All yet) > > […] > an > > […] > > It does give the hash, which is unique for each object. In which form > would you expect object_get_id to return object's identity? PHP > doesn't have a type of "tuple of C pointer and long integer" ;) Hmm. I think what Pavel is asking is just to make it clearer in the documentation what spl_object_hash's purpose and workings are, and perhaps make an alias to it named object_get_id so other people don't run into this confusion in the future. The name of spl_object_hash and the fact it is in the SPL and not in the engine does lead one to believe that it might do more than simply hashing the handler table and handle tuple. People might think it hashes the properties as well. David --- ## #30411 — Pavel Shevaev — 2007-07-02T18:33:56+00:00 URL: https://externals.io/message/30366#30411 · In reply to: #30410 > Hmm. I think what Pavel is asking is just to make it clearer in the > documentation what spl_object_hash's purpose and workings are, and perhaps > make an alias to it named object_get_id so other people don't run into this > confusion in the future. > > The name of spl_object_hash and the fact it is in the SPL and not in the > engine does lead one to believe that it might do more than simply hashing > the handler table and handle tuple. People might think it hashes the > properties as well. Exactly, this is what I wanted to say, thanks ;) > David -- Best regards, Pavel --- ## #30412 — Antony Dovgal — 2007-07-02T18:37:59+00:00 URL: https://externals.io/message/30366#30412 · In reply to: #30410 > (Many apologies for the double e-mail. Ugh, I'm not used to hitting Reply To > All yet) > > > […] > > Hmm. I think what Pavel is asking is just to make it clearer in the > documentation what spl_object_hash's purpose and workings are That's fine, the docu team would gladly accept any help and patches. > and perhaps > make an alias to it named object_get_id so other people don't run into this > confusion in the future. I'd like to avoid creating misleading aliases, which would not be usable on a shared hosting in the next 10 years anyway. > The name of spl_object_hash and the fact it is in the SPL and not in the > engine does lead one to believe that it might do more than simply hashing > the handler table and handle tuple. People might think it hashes the > properties as well. People won't think anything like that if we fix the documentation, so let's do it. -- Wbr, Antony Dovgal --- Next page: https://externals.io/message/30366.md?page=2