# Summary of string conversion problem - Thread: https://externals.io/message/5921 - Original archive: https://news-web.php.net/php.internals/5921 - Started by Andi Gutmans on 2003-12-01T17:49:09+00:00 - Messages: 4 - 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 --- ## #5921 — Andi Gutmans — 2003-12-01T17:49:09+00:00 URL: https://externals.io/message/5921#5921 Hey, Let's try and summarize this discussion and try and see what solution we can come up with. The change which was made in convert_to_string() is quite problematic. It touches a very fundamental engine function and changes the behavior of tons of places. For example: a) include $obj; will not error out but convert the object to a string and then include it. b) $obj[2] = 3; (where $obj implements a __toString function) isn't quite defined anymore. Should this work? c) $arr[$obj] would suddenly work according the __toString(). Not to say that all sorts of bugs would probably be introduced because all places which call convert_to_string() would have to be checked. The second patch which automatically calls __toString() on parameters isn't quite as bad but I am really not sure this is what we want. Do we want PHP scripts to become much less readable and have people save their strings in objects and pass those around? How will passing such objects by reference work with extension functions which expect their string parameter to be by reference? As you can see there are LOTS of problems this would introduce (and most likely more than I could think of). In the past it was agreed that __toString() would be called explicitly but we would let "print" to be overloaded. Right now, I think making people call it explicitly is the best way to go and the way Java chose too (not that I thnk we necessarily need to go the same way but there were some smart ppl who thought of these issues before us). I do think that SimpleXML has to be tailored for because I truly think that it's the best addition to PHP 5 including the new OOP features. So the question really boils down to what exactly the SimpleXML extension requires? Can't it return a string when it's in read mode? Let's try and find the right balance between ease-of-use for extensions such as SimpleXML and verbosity and a PHP which is not error-prone and as consistent as possible. Marcus, reverting the patch was nothing personal. You can see I have technical issues with it. I think you have been doing some great patches and you know it :) Andi --- ## #5930 — Christian Schneider — 2003-12-01T18:53:12+00:00 URL: https://externals.io/message/5921#5930 · In reply to: #5921 I'm not really sure on what's the best way to handle the string conversion problem, as I haven't worked with SimpleXML yet. Andi's examples on the other hand aren't convincing enough for me so here my comments: Andi Gutmans wrote: > a) include $obj; will not error out but convert the object to a string > and then include it. I'd expect that in most cases this would be an invalid filename which would result in an error message. Nothing lost there. > b) $obj[2] = 3; (where $obj implements a __toString function) isn't > quite defined anymore. Should this work? The bracket syntax has been deprecated in PHP4 already. Giving a warning on a high error reporting level seems do the job for me. > c) $arr[$obj] would suddenly work according the __toString(). I remember this being requested as a feature anyway ;-) > go and the way Java chose too (not that I thnk we necessarily need to go > the same way but there were some smart ppl who thought of these issues > before us). I don't like Java being used for PHP design decisions really. The syntax is cumbersome and has a different focus (static type checking). Don't forget that a lot of design decisions for Java were made in the 80s. My $.2, - Chris --- ## #5955 — Marcus Boerger — 2003-12-01T22:10:16+00:00 URL: https://externals.io/message/5921#5955 · In reply to: #5921 Hello Andi, Monday, December 1, 2003, 6:49:09 PM, you wrote: > Hey, > Let's try and summarize this discussion and try and see what solution we > can come up with. > The change which was made in convert_to_string() is quite problematic. It > touches a very fundamental engine function and changes the behavior of tons > of places. For example: > a) include $obj; will not error out but convert the object to a string and > then include it. > b) $obj[2] = 3; (where $obj implements a __toString function) isn't quite > defined anymore. Should this work? > c) $arr[$obj] would suddenly work according the __toString(). > Not to say that all sorts of bugs would probably be introduced because all > places which call convert_to_string() would have to be checked. > The second patch which automatically calls __toString() on parameters isn't > quite as bad but I am really not sure this is what we want. Do we want PHP > scripts to become much less readable and have people save their strings in > objects and pass those around? How will passing such objects by reference > work with extension functions which expect their string parameter to be by > reference? > As you can see there are LOTS of problems this would introduce (and most > likely more than I could think of). > In the past it was agreed that > __toString() would be called explicitly but we would let "print" to be > overloaded. > Right now, I think making people call it explicitly is the best way to go > and the way Java chose too (not that I thnk we necessarily need to go the > same way but there were some smart ppl who thought of these issues before us). > I do think that SimpleXML has to be tailored for because I truly think that > it's the best addition to PHP 5 including the new OOP features. > So the question really boils down to what exactly the SimpleXML extension > requires? Can't it return a string when it's in read mode? > Let's try and find the right balance between ease-of-use for extensions > such as SimpleXML and verbosity and a PHP which is not error-prone and as > consistent as possible. > Marcus, reverting the patch was nothing personal. > You can see I have technical issues with it. I think you have been doing > some great patches and you know it :) The summary of my productive thoughts on this: Hmmm, the minimum needed is to allow: whatever((string)$obj) then. The solution to this would be another object handler, say make_printable() and move the __toString() Call from the cast_object handler into this new one AND partly reintroduce my patch and voila all are happy? Maybe this is a really cool idea because it allows all kinds of 'cool' objects to be written in C, it allows all kinds of language bindings but without the HIGH __toString() WTF factor (minimal compareable to C++ autoconversion problems for example). -- Best regards, Marcus mailto:helly@php.net --- ## #5956 — Michael Walter — 2003-12-01T22:19:41+00:00 URL: https://externals.io/message/5921#5956 · In reply to: #5930 Christian Schneider wrote: >[...] > > […] > > > I remember this being requested as a feature anyway ;-) > The feature request was about using objects as hash indices, not their string representation (IIRC). Cheers, Michael