# Return value of convert_to_*() - Thread: https://externals.io/message/27204 - Original archive: https://news-web.php.net/php.internals/27204 - Started by Andrei Zmievski on 2006-12-27T20:02:29+00:00 - Messages: 10 - 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 --- ## #27204 — Andrei Zmievski — 2006-12-27T20:02:29+00:00 URL: https://externals.io/message/27204#27204 Antony and I just had a spirited discussion on IRC about his latest patches to convert_to_unicode() and convert_to_string(). The specific troublesome point was conversion of IS_OBJECT type. His point was that since all we care about is the end result, then the function should return SUCCESS regardless of whether the object could convert itself to a string or whether we forced the conversion and got a simple "Object" string. I do not subscribe to this point of view. I added return values to conversion functions precisely because I wanted to distinguish between "good" and "forced" conversions. We can convert anything to anything, that's not a problem, but in certain cases I do care that we tried to convert IS_OBJECT to IS_STRING and couldn't do it without falling back onto the "Object" crutch. One such place is zend_parse_parameters(). If you say zpp(..., "s", &str, &str_len) and the user passes an object without __toString() method, zpp() should issue an error saying that it expected a string and got an object instead, even if we "forced" the conversion result to be a string in convert_to_string(). My problem with considering "Object" a "successful" conversion is this: why do we issue E_RECOVERABLE error if the object couldn't convert itself to a string? Why should the user be able to catch that and not my code? Please tell me that this is a valid point of view. -Andrei --- ## #27205 — Antony Dovgal — 2006-12-27T20:23:11+00:00 URL: https://externals.io/message/27204#27205 · In reply to: #27204 > Antony and I just had a spirited discussion on IRC about his latest > patches to convert_to_unicode() and convert_to_string(). The specific > troublesome point was conversion of IS_OBJECT type. His point was that > since all we care about is the end result, then the function should > return SUCCESS regardless of whether the object could convert itself to > a string or whether we forced the conversion and got a simple "Object" > string. I do not subscribe to this point of view. I added return values > to conversion functions precisely because I wanted to distinguish > between "good" and "forced" conversions. Why do you want that? "Bad" conversion is failed conversion, that's the case when you get `E_RECOVERABLE_ERROR` and it bails out. I consider all the other cases are "good" conversions, since we've got the result we requested and have SUCCESSfully converted the object into string. > One such place is zend_parse_parameters(). If you say zpp(..., "s", &str, &str_len) and > the user passes an object without __toString() method, zpp() should > issue an error saying that it expected a string and got an object > instead, even if we "forced" the conversion result to be a string in > convert_to_string(). An error? You mean this one: zend_error(E_NOTICE, "Object of class %v to string conversion", Z_OBJCE_P(op)->name); ? We already have it, no need for a new error. It's perfectly legal to do it in 5.2 and I don't see why PHP6 is different. IMO it's same as changing the E_RECOVERABLE to `E_ERROR` - users won't have any way to "workaround" it, even though this was the original intention of E_RECOVERABLE. -- Wbr, Antony Dovgal --- ## #27206 — Andrei Zmievski — 2006-12-27T21:12:10+00:00 URL: https://externals.io/message/27204#27206 · In reply to: #27205 > Why do you want that? > "Bad" conversion is failed conversion, that's the case when you get > `E_RECOVERABLE_ERROR` and it bails out. Yes, I want that function to return FAILURE when we issue E_RECOVERABLE_ERROR. Exactly what I was talking about. > > > […] > > An error? You mean this one: > zend_error(E_NOTICE, "Object of class %v to string conversion", > Z_OBJCE_P(op)->name); > ? > We already have it, no need for a new error. I want zend_parse_parameters() to issue a warning, saying "foo() expects parameter 1 to be string, object given". I do not consider "Object" to be a valid conversion for this purpose. > It's perfectly legal to do it in 5.2 and I don't see why PHP6 is > different. > IMO it's same as changing the E_RECOVERABLE to `E_ERROR` - users > won't have any way to "workaround" it, even though this was the > original intention of E_RECOVERABLE. It is not the same. `E_ERROR` stops execution. Returning FAILURE from convert_to_string() is simply a flag that lets calling code know what happened. -Andrei --- ## #27207 — Antony Dovgal — 2006-12-27T21:23:56+00:00 URL: https://externals.io/message/27204#27207 · In reply to: #27206 > > […] > > It is not the same. `E_ERROR` stops execution. Returning FAILURE from > convert_to_string() is simply a flag that lets calling code know what > happened. Failure in zend_parse_parameters() means that function itself will not be executed, which is a major change in behaviour and I don't think we really want it. -- Wbr, Antony Dovgal --- ## #27248 — Andrei Zmievski — 2007-01-03T18:51:44+00:00 URL: https://externals.io/message/27204#27248 · In reply to: #27207 Only in cases where people blindly pass objects where strings are expected. It won't break anything for those objects that know how to convert themselves. -Andrei > > > […] > > Failure in zend_parse_parameters() means that function itself will not > be executed, which is a major change in behaviour and I don't think we > really want it. > > -- > Wbr, Antony Dovgal --- ## #27250 — Antony Dovgal — 2007-01-03T18:58:41+00:00 URL: https://externals.io/message/27204#27250 · In reply to: #27248 > Only in cases where people blindly pass objects where strings are > expected. It won't break anything for those objects that know how to > convert themselves. It still see no reasons for this particular change in behavior. It was allowed in the past and I'm sure it should be still okay to do it as long as there are no technical reasons to prevent it, which I'm unable to see. > > > > […] > -- Wbr, Antony Dovgal --- ## #27251 — Andrei Zmievski — 2007-01-03T19:17:53+00:00 URL: https://externals.io/message/27204#27251 · In reply to: #27250 So you're okay with substr($obj, 0, 3) giving you "Obj" ?? To me, that seems broken, regardless of whether we had it "working" in the past. -Andrei > > > […] > > It still see no reasons for this particular change in behavior. > It was allowed in the past and I'm sure it should be still okay to do > it as long as there are no technical reasons to prevent it, which I'm > unable to see. > > > > […] > > > -- > Wbr, Antony Dovgal --- ## #27253 — Marcus Boerger — 2007-01-03T20:00:29+00:00 URL: https://externals.io/message/27204#27253 · In reply to: #27251 Hello Andrei, we had a long decision about this issue already and decided that the only reason for "Object..." in 5.0 and 5.1 was the lack of ability to fix __toString() prior to 5.2. The current 5.2/6.0 behavior is what we wanted in the first place and hence correct, or do we need to restart the discussion again? Or am I again missing something here? best regards marcus Wednesday, January 3, 2007, 8:17:53 PM, you wrote: > So you're okay with substr($obj, 0, 3) giving you "Obj" ?? > To me, that seems broken, regardless of whether we had it "working" in > the past. > -Andrei > > > […] Best regards, Marcus --- ## #27255 — Antony Dovgal — 2007-01-03T20:28:20+00:00 URL: https://externals.io/message/27204#27255 · In reply to: #27251 > So you're okay with substr($obj, 0, 3) giving you "Obj" ?? > > To me, that seems broken, regardless of whether we had it "working" in > the past. I can name you quite a number of things which seem broken to me (or aesthetically wrong), but I don't think it means I can "fix" them freely.. -- Wbr, Antony Dovgal --- ## #27256 — Andrei Zmievski — 2007-01-03T20:35:47+00:00 URL: https://externals.io/message/27204#27256 · In reply to: #27253 > Hello Andrei, > > we had a long decision about this issue already and decided that the > only reason for "Object..." in 5.0 and 5.1 was the lack of ability to > fix __toString() prior to 5.2. The current 5.2/6.0 behavior is what we > wanted in the first place and hence correct, or do we need to restart > the discussion again? Or am I again missing something here? I guess it's fine, since it's a catchable fatal error. -Andrei