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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
