Home » Database » DB_DataObject » Bug #3645

[2005-02-28 18:59 UTC] ojai at nerim dot net

Description:
------------
Hi,

You implement a wrong clone() function in DB_Dataobject on line 190 (current cvs version). I do need a such compatibility trick, but your version of clone() does not call __clone() on the objects it duplicates.

I think you should use PHP_Compat's one.

Cheers

[2005-03-01 09:55 UTC] ojai at nerim dot net

That's what I'm currrently doing : including PHP_Compat's version before DB_DataObject gets loaded.

But your use of __clone() is very obscure to me. The point is that if you're concerned with a possible performance hit, then you should add an option to the Generator, to suppress this __clone() method, from the generated class.

This way PHP_Compat's clone() method won't call anything, since if method_exists ($object, '__clone') will evaluate to false.

Second point : I don't see why you return $this from DO::__clone(). I don't even see why this __clone() method is needed. The PHP manual does not mention anything about the return value. PHP5 clones the object by itself, and then it calls the __clone() method if it exists, so that internal references get replicated if the developer wishes so.

Last, but not least : I understand your point about "clone is only created by dataobjects if it does not exist". But, I have a particular anger against this sort of behaviour : when some classes declare global identifiers, or change global settings, so that you suddenly observe a mysterious bug at the other end of your application, driving all your investigations to /dev/null. For small apps that's ok, but when your object tree looks like an old oak that's different...

Anyway, it gets a bit more complicated with the #3649 bug that I just posted : some internal references seem pretty hard to replicate under PHP4. I'd greatly appreciate if you could give your opinion on this bug.

Thanks