#49987 [Bgs]: __clone and __toString behave inconsistently

ID: 49987 User updated by: queenzeal at gmail dot com Reported By: queenzeal at gmail dot com Status: Bogus Bug Type: Feature/Change Request PHP Version: 5.3.0 New Comment: What errors would locking __clone down prevent? Since it is locked down, I can't exactly play around with it to find out, heh. Previous Comments: ------------------------------------------------------------------------ [2009-10-25 01:41:21] 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-24 23:29:44] 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-24 22:26:25] 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 20:43:03] 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 ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=49987&edit=1