# Missing __toString() part - Thread: https://externals.io/message/23875 - Original archive: https://news-web.php.net/php.internals/23875 - Started by Marcus Boerger on 2006-06-03T11:42:12+00:00 - Messages: 73 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/23875.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 --- ## #23875 — Marcus Boerger — 2006-06-03T11:42:12+00:00 URL: https://externals.io/message/23875#23875 Hello guys, the attached patch closes one more __toString() part. It allows to use objects that define __toString as indexes to arrays. What do you guys think about this, should we add it or stay with the old behavior that didn't allow objects as indexes at all. -- Best regards, Marcus mailto:mail@marcus-boerger.de --- ## #23876 — Pierre — 2006-06-03T12:40:29+00:00 URL: https://externals.io/message/23875#23876 · In reply to: #23875 Hi, > Hello guys, > > the attached patch closes one more __toString() part. It allows > to use objects that define __toString as indexes to arrays. What do > you guys think about this, should we add it or stay with the old > behavior that didn't allow objects as indexes at all. $arr[new Test] = 'abc'; makes very little sense to me, as well as $a = new Test; $arr[$a] = 'abc'; Do we really want to support that? --Pierre --- ## #23877 — Marcus Boerger — 2006-06-03T12:47:27+00:00 URL: https://externals.io/message/23875#23877 · In reply to: #23876 Hello Pierre, ever thought that we use tests to check special behavior and that those snippets have little to do with real applications? Obviously not. The idea behind is that for instance you might use an array as a translation and use an object to *calculate* the index. Saturday, June 3, 2006, 2:40:29 PM, you wrote: > Hi, > > > […] > $arr[new Test] = 'abc'; > makes very little sense to me, as well as > $a = new Test; $arr[$a] = 'abc'; > Do we really want to support that? > --Pierre Best regards, Marcus --- ## #23878 — Michael Walter — 2006-06-03T12:49:50+00:00 URL: https://externals.io/message/23875#23878 · In reply to: #23876 Yes definitely, that functionality would be useful. Regards, Michael > Hi, > > > > […] > > $arr[new Test] = 'abc'; > > makes very little sense to me, as well as > > $a = new Test; $arr[$a] = 'abc'; > > Do we really want to support that? > > --Pierre --- ## #23879 — Pierre — 2006-06-03T12:52:45+00:00 URL: https://externals.io/message/23875#23879 · In reply to: #23877 > Hello Pierre, > > ever thought that we use tests to check special behavior and that > those snippets have little to do with real applications? Obviously > not. The idea behind is that for instance you might use an array as > a translation and use an object to *calculate* the index. I understood that. The "magic" behind __toString was my point. However adding it could help to be consistent with the other magic operations... --Pierre --- ## #23880 — Robert Amos — 2006-06-03T12:55:00+00:00 URL: https://externals.io/message/23875#23880 · In reply to: #23877 Hi, Is it really worth enabling a whole new area where problems could occur just for this? Can you provide an example of where it might actually be considered useful and not just being lazy? -Rob > Hello Pierre, > > ever thought that we use tests to check special behavior and that > those snippets have little to do with real applications? Obviously > not. The idea behind is that for instance you might use an array as > a translation and use an object to *calculate* the index. > > Saturday, June 3, 2006, 2:40:29 PM, you wrote: > > > […] > > > […] > > > […] > > > […] > > > […] > > > […] > > > […] > > > > Best regards, > Marcus > > -- > > > > -- Xnyo - http://xnyo.odynia.org/ --- ## #23881 — Marcus Boerger — 2006-06-03T13:02:51+00:00 URL: https://externals.io/message/23875#23881 · In reply to: #23880 Hello Robert, well lazy is a good point here but __toString is all about lazyness. Then again as said you might want to have objects naturally convert to strings whereever possible. Generally when providing a __toString implementation you say that you want this. And then you might as well expect that your objects can be used as index to arrays. The example is as said an object that can be used to calculate the index to an array. Assuming you deal with persons derived from a database as classes, your person objects might be implmeneted so that __toString simply returns the name of the persons. Now when your application also has an array that stores more information about the persons it would be nice if you could access that array direectly by your peson objects. best regards marcus Saturday, June 3, 2006, 2:55:00 PM, you wrote: > Hi, > Is it really worth enabling a whole new area where problems could > occur just for this? Can you provide an example of where it might > actually be considered useful and not just being lazy? > -Rob > > > […] > -- > Xnyo - http://xnyo.odynia.org/ Best regards, Marcus --- ## #23882 — Robert Amos — 2006-06-03T13:05:23+00:00 URL: https://externals.io/message/23875#23882 · In reply to: #23881 Thats fair, as long as it doesn't result in any unwanted behaviour then I'm +1. -Rob > Hello Robert, > > well lazy is a good point here but __toString is all about lazyness. > Then again as said you might want to have objects naturally convert > to strings whereever possible. Generally when providing a __toString > implementation you say that you want this. And then you might as well > expect that your objects can be used as index to arrays. > > The example is as said an object that can be used to calculate the > index to an array. Assuming you deal with persons derived from > a database as classes, your person objects might be implmeneted so > that __toString simply returns the name of the persons. Now when your > application also has an array that stores more information about the > persons it would be nice if you could access that array direectly by > your peson objects. > > best regards > marcus > > Saturday, June 3, 2006, 2:55:00 PM, you wrote: > > > […] > > > […] > > > […] > > > […] > > > > […] > > > > > Best regards, > Marcus > > -- Xnyo - http://xnyo.odynia.org/ --- ## #23883 — Pierre — 2006-06-03T13:09:49+00:00 URL: https://externals.io/message/23875#23883 · In reply to: #23882 > Thats fair, as long as it doesn't result in any unwanted behaviour then I'm +1. Good luck ;-) --Pierre --- ## #23884 — Derick Rethans — 2006-06-03T13:34:42+00:00 URL: https://externals.io/message/23875#23884 · In reply to: #23881 > Hello Robert, > > well lazy is a good point here but __toString is all about lazyness. > Then again as said you might want to have objects naturally convert > to strings whereever possible. Generally when providing a __toString > implementation you say that you want this. And then you might as well > expect that your objects can be used as index to arrays. > > The example is as said an object that can be used to calculate the > index to an array. Assuming you deal with persons derived from > a database as classes, your person objects might be implmeneted so > that __toString simply returns the name of the persons. Now when your > application also has an array that stores more information about the > persons it would be nice if you could access that array direectly by > your peson objects. Makes sense to me, so +1. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #23885 — Andrew Yochum — 2006-06-03T14:36:39+00:00 URL: https://externals.io/message/23875#23885 · In reply to: #23875 > Hello guys, > > the attached patch closes one more __toString() part. It allows > to use objects that define __toString as indexes to arrays. What do > you guys think about this, should we add it or stay with the old > behavior that didn't allow objects as indexes at all. Like others who have contributed to the thread I agree that it would be useful, but I think using __toString() wrong for this. There is a confusion two ideas here: 1. The string representation of an object, probably human readable, lucent string. 2. A unique hash of an object use to identify it programmatically, and likely unique. Probably a non-human friendly, opaque value. These are not the same thing. The latter is what, IMO, would be used for an objects value as an index into an array, not the former. The latter is available ... currently I do this like so: class a{ public function __toString() { return 'an object';}} $foo = new a; $bar = new a; $arr = new array() $arr[(string)$foo] = $foo; // The index is "Object id #1" $arr[(string)$bar] = $bar; // The index is "Object id #2" Note that the __tostring method is not used in the cast - a spearate issue, but needs to be pointed out for this issue. Therefore my suggested alternative to Marcus' patch is: When Objects are used in array index context, use the object ID or some variation. And, possibly, provide a magic method, or interface to generate an hash value of an object. Regards, Andrew -- Andrew Yochum Plexpod andrew@plexpod.com 718-360-0879 --- ## #23886 — Ilia Alshanetsky — 2006-06-03T16:16:41+00:00 URL: https://externals.io/message/23875#23886 · In reply to: #23875 I think this is a potentially missing bit of functionality we definitely need to consider including. There is really no technical reason why $foo[new ToStringObject] = "bar"; cannot work or a reason why it shouldn't as far as functionality goes. Ilia Alshanetsky > Hello guys, > > the attached patch closes one more __toString() part. It allows > to use objects that define __toString as indexes to arrays. What do > you guys think about this, should we add it or stay with the old > behavior that didn't allow objects as indexes at all. > > -- > Best regards, > Marcus mailto:mail@marcus-boerger.de > a(); Why shouldn't this? $b[$a] = 1; key($b)->a(); I have always looked a PHP array as having 2 places to store things. You can store stuff in the key with the caveat/feature that it must be unique and you can store whatever you want in the value part. Only allowing strings and integers in the key seems like an arbitrary restriction to me. As long as the key is something we can somehow uniquely identify I think we should aim to support it. -Rasmus Ilia Alshanetsky wrote: > I think this is a potentially missing bit of functionality we definitely > need to consider including. There is really no technical reason why > $foo[new ToStringObject] = "bar"; cannot work or a reason why it > shouldn't as far as functionality goes. > > > Ilia Alshanetsky > > > > > > > > […] --- ## #23888 — Marcus Boerger — 2006-06-03T16:38:59+00:00 URL: https://externals.io/message/23875#23888 · In reply to: #23885 Hello Andrew, Saturday, June 3, 2006, 4:36:39 PM, you wrote: > > > […] > Like others who have contributed to the thread I agree that it would be > useful, but I think using __toString() wrong for this. There is a > confusion two ideas here: > 1. The string representation of an object, probably human > readable, lucent string. > 2. A unique hash of an object use to identify it programmatically, > and likely unique. Probably a non-human friendly, opaque value. > These are not the same thing. The latter is what, IMO, would be used > for an objects value as an index into an array, not the former. > The latter is available ... currently I do this like so: > class a{ public function __toString() { return 'an object';}} > $foo = new a; > $bar = new a; > $arr = new array() > $arr[(string)$foo] = $foo; // The index is "Object id #1" > $arr[(string)$bar] = $bar; // The index is "Object id #2" > Note that the __tostring method is not used in the cast - a spearate > issue, but needs to be pointed out for this issue. > Therefore my suggested alternative to Marcus' patch is: > When Objects are used in array index context, use the object ID or some > variation. And, possibly, provide a magic method, or interface to > generate an hash value of an object. We cannot use the object id since that is not necessarily unique. For the same reason SplObjectStorage cannot be done in userland. However what you mention here is right. Other languages offer to magic functions. A stringify one and a hashing one. But then again i don't think we should add yet another magic feature. best regards marcus --- ## #23889 — Marcus Boerger — 2006-06-03T16:43:26+00:00 URL: https://externals.io/message/23875#23889 · In reply to: #23887 Hello Rasmus, though you are probably right here your idea brought to it's full extend will bring a major BC break. Just consider we had both key and value as a zval then the current behavior would change for quite a lot of situations including not only objects and resources but also booleans, floats and NULL. Right now everybody is used to the restiction that an array key can only be a string or an integer and if not it is either not acceptable as a key at all or is being converted to either one. best regards marcus Saturday, June 3, 2006, 6:30:38 PM, you wrote: > I don't understand why using the object as an index would trigger a > __toString() call. PHP's array indices are not defined to be strings, > so I don't see this as being a string context use and thus __toString() > shouldn't be called. > I also don't see why we need to make a distinction between the key and > the value here if there is any way we can avoid it. > For example, this obviously works: > class foo { > function a() { echo "a"; } > } > $a = new foo(); > $b[1] = $a; > $b[1]->a(); > Why shouldn't this? > $b[$a] = 1; > key($b)->a(); > I have always looked a PHP array as having 2 places to store things. > You can store stuff in the key with the caveat/feature that it must be > unique and you can store whatever you want in the value part. Only > allowing strings and integers in the key seems like an arbitrary > restriction to me. As long as the key is something we can somehow > uniquely identify I think we should aim to support it. > -Rasmus > Ilia Alshanetsky wrote: > > […] Best regards, Marcus --- ## #23890 — Stanislav Malyshev — 2006-06-03T17:03:24+00:00 URL: https://externals.io/message/23875#23890 · In reply to: #23887 RL>>I don't understand why using the object as an index would trigger a RL>>__toString() call. PHP's array indices are not defined to be strings, RL>>so I don't see this as being a string context use and thus RL>>__toString() shouldn't be called. If so, what should be the actual key in the hash? -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115 --- ## #23891 — Rasmus Lerdorf — 2006-06-03T17:11:58+00:00 URL: https://externals.io/message/23875#23891 · In reply to: #23889 Right, just let me clarify. My point here was that if we are going to make a change here, we should do it correctly and come up with a way to create a unique hash of the object so it really can be used as an array index. Magically calling __toString() in a case where we don't have an explicit string context sounds half-assed and non-obvious to me. If you want that ability, simply do: $a[(string)$obj] and it is obvious what you are doing. -Rasmus Marcus Boerger wrote: > Hello Rasmus, > > though you are probably right here your idea brought to it's full > extend will bring a major BC break. Just consider we had both key > and value as a zval then the current behavior would change for quite > a lot of situations including not only objects and resources but also > booleans, floats and NULL. > > Right now everybody is used to the restiction that an array key can > only be a string or an integer and if not it is either not acceptable > as a key at all or is being converted to either one. > > best regards > marcus > > Saturday, June 3, 2006, 6:30:38 PM, you wrote: > > > […] > > > […] > > > […] > > > […] > > > […] > > > […] > > > […] > > > […] > > > […] > > > > > Best regards, > Marcus --- ## #23892 — Rasmus Lerdorf — 2006-06-03T17:13:56+00:00 URL: https://externals.io/message/23875#23892 · In reply to: #23890 Stanislav Malyshev wrote: > RL>>I don't understand why using the object as an index would trigger a > RL>>__toString() call. PHP's array indices are not defined to be strings, > RL>>so I don't see this as being a string context use and thus > RL>>__toString() shouldn't be called. > > If so, what should be the actual key in the hash? I am sure we could come up with some sort of hashing mechanism that would uniquely identify an object. And perhaps even expose it to the user with a __hashOf(). But again, I am not sure we want to open up that can of worms. Like I said, I think this is the more correct approach and that we shouldn't try to use a magic __toString() call here to attempt to emulate this. -Rasmus --- ## #23893 — Gwynne — 2006-06-03T21:15:50+00:00 URL: https://externals.io/message/23875#23893 · In reply to: #23892 > > […] > I am sure we could come up with some sort of hashing mechanism that > would uniquely identify an object. And perhaps even expose it to > the user with a __hashOf(). But again, I am not sure we want to > open up that can of worms. Like I said, I think this is the more > correct approach and that we shouldn't try to use a magic __toString > () call here to attempt to emulate this. I'm new to this list, so I apologize if I'm out of line in commenting here, but it's my opinion that the advantages offered by a __hash() magic function would outweigh the inevitable complexity and issues involved. I imagine that it would be a strict semantic: If the class of the object being indexed into the array doesn't define a magic __hash() function, it would be a warning or even fatal error; no attempt would/should be made to calculate a hash based on anything other than what the object is willing to call itself. Gwynne SkyTag Software --- ## #23894 — Jasper Bryant-Greene — 2006-06-03T22:12:30+00:00 URL: https://externals.io/message/23875#23894 · In reply to: #23893 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Gwynne wrote: > I'm new to this list, so I apologize if I'm out of line in commenting > here, but it's my opinion that the advantages offered by a __hash() > magic function would outweigh the inevitable complexity and issues > involved. I imagine that it would be a strict semantic: If the class of > the object being indexed into the array doesn't define a magic __hash() > function, it would be a warning or even fatal error; no attempt > would/should be made to calculate a hash based on anything other than > what the object is willing to call itself. I would imagine that __hash() or whatever it is called would be defined on all objects and implemented internally in PHP, and would simply generate some internal hash that is unique for all objects. - -- Jasper Bryant-Greene General Manager Album Limited http://www.album.co.nz/ 0800 4 ALBUM jasper@album.co.nz 021 708 334 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEgglOFfAeHhDzT4gRA2JtAKC3rkHI6QGo5yYQyHBbuZzG068D6wCgqej3 QqtgAcCeC5qo8ja2oCB4aUw= =2C/T -----END PGP SIGNATURE --- ## #23895 — Gwynne — 2006-06-03T23:54:00+00:00 URL: https://externals.io/message/23875#23895 · In reply to: #23894 > I would imagine that __hash() or whatever it is called would be > defined > on all objects and implemented internally in PHP, and would simply > generate some internal hash that is unique for all objects. That might work for initial testing, but applying that sort of hash function to objects identified purely by strings, to take one example, doesn't work. (in_array(new Str("A"), array(new Str("A"))) is one failure mode that comes instantly to mind. It's inevitable that two non-identical objects would contain identical data. Think of the reasons behind C++'s operator==, or for those of you familiar with Carbon programming under MacOS, the hash callbacks provided by CoreFoundation's various container types. Gwynne SkyTag Software --- ## #23896 — bertrand Gugger — 2006-06-04T00:45:24+00:00 URL: https://externals.io/message/23875#23896 · In reply to: #23893 Gwynne wrote: > no attempt > would/should be made to calculate a hash based on anything other than > what the object is willing to call itself. +1 here oo people have a name for that. and implement what's needed. I'm surely out of talk , but please keep indexes scalar. The toString way is anyway rotten. The id way for an object is headaches. -- toggg --- ## #23897 — Andi Gutmans — 2006-06-04T00:57:27+00:00 URL: https://externals.io/message/23875#23897 · In reply to: #23888 Generally I think it's a good thing to allow to use objects as array indexes. There are really two ways of doing it: a) Try and find a way to create unique ideas. b) Support __toString() and leave it up to the author. I have a bit of a hard time finding a solution to (a) unless the unique id is a string. Not that I think having it as a string is necessarily a bad thing but I'd be interested in hearing what others think. Supporting __toString() is the easiest way to go, especially as it wouldn't lead to BC breaks. It would be up to the author to make that a unique key like "Db#Person#1" but then they couldn't use that with "print" because the value the class author would want there would probably not be the one he'd want in array access. Anyone got any thoughts, how bad of a break it would be if we did create a unique id of objects, whether string or int? That's something we probably could do for PHP 6 esp. if string is acceptable. Andi At 09:38 AM 6/3/2006, Marcus Boerger wrote: >Hello Andrew, > >Saturday, June 3, 2006, 4:36:39 PM, you wrote: > > > […] > > > […] > > > […] > > > […] > >We cannot use the object id since that is not necessarily unique. >For the same reason SplObjectStorage cannot be done in userland. >However what you mention here is right. Other languages offer to >magic functions. A stringify one and a hashing one. But then again >i don't think we should add yet another magic feature. > >best regards >marcus --- ## #23898 — Pierre — 2006-06-04T01:01:00+00:00 URL: https://externals.io/message/23875#23898 · In reply to: #23897 Hi, > Generally I think it's a good thing to allow to use objects as array > indexes. There are really two ways of doing it: > a) Try and find a way to create unique ideas. > b) Support __toString() and leave it up to the author. I see a third choice, which I prefer: c) leave the choice to the user, he knows better what to do with his object (like implementing his own get(Hash|Key) method. --Pierre --- ## #23899 — Andi Gutmans — 2006-06-04T01:12:33+00:00 URL: https://externals.io/message/23875#23899 · In reply to: #23898 Yep that is also a choice, although it can be advantageous to have an automatic (a) which people just now works, always... I don't think it's a critical problem because as you pointed out people can deal with it, but I think it'd be nice to provide some tools to make life easier. At 06:01 PM 6/3/2006, Pierre wrote: >Hi, > > > > […] > >I see a third choice, which I prefer: > >c) leave the choice to the user, he knows better what to do with his > object (like implementing his own get(Hash|Key) method. > > >--Pierre --- Next page: https://externals.io/message/23875.md?page=2