Re: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
| From: | Andi Gutmans | Date: | Mon, 01 Dec 2003 14:17:58 +0000 |
| Subject: | Re: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-5875@lists.php.net to get a copy of this message | ||
At 01:21 PM 12/1/2003 +0000, Wez Furlong wrote:
WF>> The reason I mentioned this is that serialize($obj) is currently WF>> meaningless for COM objects, so people are using WF>> serialize((string)$obj) to get a string representation. I don't understand - what is the meaning of serialize((string)$obj)? What should it return? Just pretend I didn't mention serialization... you're getting off topic :-) What I'm trying to say is that (string)$obj really should work (as it does currently) for overloaded objects because they might not have a __toString() method, and if they do, we shouldn't overload it in PHP with some kludge method because we will probably get it wrong (just take a look at the kind of kludge we have for IEnumVariant support in the 4.x COM extension!).I think there are two options: a) Revert the cast operator patch and don't support automatic string conversion by PHP objects (i.e. allowing overloading extensions to support it). But you still shouldn't expect automagical conversions when passing COM objects to functions which accept strings as a parameter. b) Add a __toString() C API function and make $obj->__toString() call that. It would mean that your COM example would look like serialize($com_object->__toString()). Personally, I prefer (b) but I think I can live with both. Note: In both cases you won't have automatic conversions. Andi