ID: 41221 User updated by: oliver dot graetz at gmx dot de Reported By: oliver dot graetz at gmx dot de Status: Open Bug Type: Documentation problem Operating System: Windows XP -PHP Version: Irrelevant +PHP Version: 5.2.* New Comment:
changed version from irrelevant to 5.2.* Previous Comments: ------------------------------------------------------------------------ [2007-04-29 06:09:22] 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 05:14:04] 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 04:52:19] 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 ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=41221&edit=1
