Re: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c

From: Date: Mon, 01 Dec 2003 17:01:24 +0000
Subject: Re: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-5913@lists.php.net to get a copy of this message
It can be resolved at compile-time. My main problem is not with the casting operator but with auto-casting all throughout the engine including parameter passing. I have a very bad feeling that stuff will break such as array offset assigning. Andi At 04:58 PM 12/1/2003 +0000, Wez Furlong wrote:
It's probably a lot higher than you think, given that other object models are likely to use a similar naming convention :-) I still think it is a bad idea to hide methods like this for overloaded objects; we have the cast handler and (to my eyes) $foo = (string)$obj; looks simpler and less magical than: $foo = $obj->__toString(); Plus, this latter one has the overhead of resolving the function name etc., whereas the former takes less overhead as (string) gets resolved at compile time, and the engine routes the cast using a shorter path at run time ;-) --Wez. What's the chance of having a __toString() in an external object model (note the two underscores :) Andi At 02:26 PM 12/1/2003 +0000, Wez Furlong wrote:
I favour a), if you mean that (string)$com_object will work. I'm not so bothered with userspace objects. b) is just wrong for overloaded objects; if we do some magic and either hide an existing __toString() method, or call one with the wrong parameters (it might implement one differently to the way that we expect), then we end up in trouble.


« previous php.internals (#5913) next »