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

go to bug id or search bugs for

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 Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: queenzeal at gmail dot com
New email:
PHP Version: OS:

 

 [2009-10-24 20:43 UTC] queenzeal at gmail dot com 
Description:
------------
__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 <http://php.net/language.oop5.cloning> 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:
----------------
a
a

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

Patches

Pull Requests

History

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

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] johannes@php.net 
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-2025 The PHP Group
All rights reserved. 		Last updated: Fri May 09 15:01:27 2025 UTC