|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #49987 __clone and __toString behave inconsistently
Submitted: 2009-10-24 20:43 UTC Modified: 2009-10-25 03:30 UTC
From: queenzeal at gmail dot com Assigned:
Status: Not a bug Package: Feature/Change Request
PHP Version: 5.3.0 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
9 + 42 = ?
Subscribe to this entry?

 [2009-10-24 20:43 UTC] queenzeal at gmail dot com
__toString() can be called directly but __clone() cannot.  It seems like this behavior ought to be consistent.  Either both can be called directly or neither can be called directly.

__clone()'s current behavior is documented in <> with the following:

"An object's __clone() method cannot be called directly."

The only reason I can figure for that is that without it, it'd be possible to clone a cloned object redundantly. eg. $a = clone $b->__clone().  That said, it seems to me like this can be done, already, with $a = clone clone $b, so that seems like a non-issue.

Reproduce code:
class a
    function __toString() {
        return 'a';

    function __clone() {
        return this;

$a = new a();

echo "$a\r\n";
echo $a->__toString() . "\r\n";

$b = clone $a;
$b = $a->__clone();

Expected result:

Actual result:
Fatal error: Cannot call __clone() method on objects - use 'clone $obj' instead
in C:\php\test.php on line 20


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-10-24 22:26 UTC]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at and the instructions on how to report
a bug at

Calling $obj->__clone(); would work on the $obj instance which won\'t be the usual aim. Calling $obj->__toString() is fine to work on the $obj instance.
 [2009-10-24 23:29 UTC] queenzeal at gmail dot com
You say calling __clone() directly "won\'t be the usual aim".  Is calling __toString() the "usual aim"?  If it were, than what's the point of having it be a magic function, anyway?  Because I thought the point was to make it so you can do echo $a; instead of echo $a->__toString(), but maybe I misunderstood.

And sure, calling __toString() "is fine to work on the $obj instance", but that doesn't do anything to address my post.  Besides, I acknowledge that that *works* in my original post - I'm just suggesting that it maybe shouldn't - that it ought to behave *consistently* with __clone().  If that means __toString() can't be called directly or __clone() can be called directly, I don't really care, but I do believe they ought to be consistent.

You say "this is not a bug".  Even I acknowledge as much.  That's why I put it in the "Feature/Change Request" category.  If you're going to close *every* "Feature/Change Request", how about you just remove that option from the drop down menu *entirely*.  Certainly that seems preferable to closing reports that, at best, just rehash what the submitter said in their submission.
 [2009-10-25 01:41 UTC]
Locking down __toString won#t bring any benefit, just an artificial barrier. Locking down __clone prevents errors. (oh and there are __call, __get, __set, __callStatic which can also called directly)
 [2009-10-25 03:30 UTC] queenzeal at gmail dot com
What errors would locking __clone down prevent?  Since it is locked down, I can't exactly play around with it to find out, heh.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Fri May 20 20:05:47 2022 UTC