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
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
Why do you want that?
"Bad" conversion is failed conversion, that's the case when you get
E_RECOVERABLE_ERRORand it bails out.
Yes, I want that function to return FAILURE when we issue
E_RECOVERABLE_ERROR. Exactly what I was talking about.
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.
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 toE_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
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 toE_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_ERRORstops 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
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
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 toE_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_ERRORstops 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
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.
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 toE_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_ERRORstops 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
--
Wbr,
Antony Dovgal
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
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.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 toE_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_ERRORstops 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--
Wbr, Antony Dovgal
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
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.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 toE_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_ERRORstops 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--
Wbr, Antony Dovgal
Best regards,
Marcus
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
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