Hi!
Well, as you know that was part of my original proposal ( https://wiki.php.net/rfc/object_cast_magic ). However, after talking with a few core devs about it, it seemed that separate methods are the preferred solution, as the single method requires a big switch (which isn't as clean, and will promote returning improper types, Floats when an int was asked for, etc)... For that reason, it seems more fragile to maintain, so I agreed with splitting it to multiple methods.
You mean the code implementing it would have switch? So what? It's not like using switch operator is banned in PHP world. I'm not sure also how it promotes returning float when int is requested - of course, you can have buggy code, so you can have it when you do it with separate methods. But having to implement 5 methods (you forgot booleans btw, which are used by the engine - another sign why it may not be a good idea to split) and keep them consistent may be a problem. Use cases however should drive it, so depending on this let's see which is better.
cast_object goes to zend_cast_object_tostring(), which is specifically hard-coded to return specific values for types. So rather than edit
case_object is used throughout the engine for various types. For PHP user objects it can do only strings now, but this is exactly what you wanted to change, isn't it?
that, I implemented a wrapper on-top to implement these additions. That way, the current (BC) functionality remains untouched... But I
Which functionality do you mean? I didn't mean for you just throw out string casting code, add to it. We have method specially created for casting objects to scalars, why work around it instead of using it?
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
