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! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 12:01:31 2024 UTC