php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #41221 PHP violates type casting rules
Submitted: 2007-04-29 04:52 UTC Modified: 2007-08-17 09:13 UTC
Votes:8
Avg. Score:4.6 ± 0.5
Reproduced:7 of 7 (100.0%)
Same Version:7 (100.0%)
Same OS:4 (57.1%)
From: oliver dot graetz at gmx dot de Assigned:
Status: Not a bug Package: Documentation problem
PHP Version: 5.2.* OS: Windows XP
Private report: No CVE-ID: None
View Developer Edit
 [2007-04-29 04:52 UTC] oliver dot graetz at gmx dot de 
Description:
------------
In the documentation under

http://php.net/manual/en/language.types.string.php#language.types.string.casting

it reads

"Objects are always converted to the string "Object"."

This is not true:

php -r "echo PHP_VERSION;echo new StdClass;"
5.2.2RC3-dev
Catchable fatal error: Object of class stdClass could not be converted to string in Command line code on line 1

The documentation should be changed to:

"Objects are not converted to anything unless you define a __toString() method. If you can't because you are using an engine internal class then you are busted. This is especially annoying with functions like implode() that stop working when their arguments contain such objects. Sorry for this inconvenience but we refuse to listen to any bug report about this and blindly change any complaint to BOGUS."

Of course the real fix would be providing the documented "Object" as fallback instead of raising a recoverable error. But as my documentation suggestion states: You are not listening. In my opinion the current behaviour is a real showstopper.

For further nagging read http://bugs.php.net/bug.php?id=40799


Reproduce code:
---------------
echo new StdClass;


Expected result:
----------------
Object

Actual result:
--------------
Catchable fatal error: Object of class stdClass could not be converted to string in Command line code on line 1

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-04-29 05:14 UTC] judas dot iscariote at gmail dot com 
Your rationale is plain wrong, the old behaviuor is really broken, outputting "Object" does not make any sense and is not helpful at all..(what the hell you will do with it? and no, as a debugging output is useless too, in that case use var_dump() to see the contents of the object)


About the DateTime() object, it does not implement __toString hence the message is correct, if you need such functionaly you can always extend the base object to add an string representation.


What is really not expected is objects behaving like strings in contexts you dont specifically want that.
 [2007-04-29 06:09 UTC] oliver dot graetz at gmx dot de 
"What is really not expected is objects behaving like strings in contexts you dont specifically want that."

This is against every PHP mantra. The language preaches dynamic/implicit casting since its first days. Many developers would even agree that the sole purpose of PHP is to create strings. My complaint is not to promote "Object" being a very good fallback, but about raising errors without actually having an emergency. Errors should be raised when something terrible happens.

The documentation clearly stating that EVERY object can be safely casted to a string isn't just the foundation for my complaint about something being wrong in the engine, but also a hint that the current behaviour is a clear violation of the pilosophy behind PHP.

Forcing developers to rewrite functions like implode() just to make sure they also work if somewhere in your array you have an object not implementing __toString() is just violating PHPs rule of DRY. Developers shall use as much pre-provided functions as possible since this yields the best performance AND it adheres to the priciple about PHP code being "the template around C code".

There are several ways of correcting this issue:

- Implement __toString() for all engine internal class. This should include StdClass as a base class for all objects. A default of "Object" is OK since anybody can easily override this behaviour. This kills the error messages and I think this is how it is supposed to be. If error messages are wanted then this should be configured via an INI directive "missing_to_string_raise_error" defaulting to no (but I don't think the directive is needed).

- Throw an exception instead of raising an error. This is still very annoying but at least the developer can catch and handle problems in situ and handle them according to the situation.

- Change the E_RECOVERABLE_ERROR to E_VERY_PICKY_STRICT because this just isn't an error according to basic PHP principles. At least this can be pretty safely ignored for some time...
 [2007-04-29 06:13 UTC] oliver dot graetz at gmx dot de 
changed version from irrelevant to 5.2.*
 [2007-08-17 09:13 UTC] vrana@php.net 
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

Same as bug #41750.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri May 09 08:01:35 2025 UTC