On Wed, Jun 22, 2016 at 3:14 PM, Dmitry Stogov <dmi...@zend.com> wrote:
> Hi Nikita, > > > When we developed php 7.0, we replaced most calls to get_class_name() by > simple obj->ce->name reading. > > However, this functionality was used by some 3-rd part extensions (e.g. > Zend JavaBridge and may be pecl/perl). > > These extensions create proxy classes and control remote objects through > RPC. > > Actually, we broke the previous behavior of backtrace* and > get_class()/get_parent_class() functions. > > > Backtrace may be fixed even in 7.0 with the following patch: > > > https://gist.github.com/dstogov/d84183da9b0d958dfe5cb8d711c8d677 > > > However, we can't fix get_parent_class(), because we changed > get_class_name() handler prototype (removed "parent" argument). > > get_class() may be fixed but I don't like to do this without > get_parent_class(), because they are going to be inconsistent. > > > What do you think about fixing backtrace in 7.0? > > In my opinion, it looks consistent with other "debug" functions, e.g. > var_dump() etc > > > Oz, as I understood, you already found a workaround for > get_class/get_parent_class introducing get_java_class(). right? > > so, do you think it worth to fix get_class/get_parent_class in 7.1? (I > think no) > > > Thanks. Dmitry. > Hey, changing debug backtrace to use the class name handler sounds fine. In 7.x we define it for use in "var_dump and other debugging functions", so using it in debug backtrace seems appropriate. I'm not sure about get_class/get_parent_class. I don't really understand how that is supposed to work / how it worked in PHP 5.x. Doesn't replacing those class names break any code using get_class() for anything other than display purposes? E.g. $class = get_class($obj); new $class; wouldn't work, because the returned name isn't the actual name of the class. Nikita
