Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94199
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BY2PR0201MB17842502187CCC1A7AFE7090BF2C0@BY2PR0201MB1784.namprd02.prod.outlook.com>
References: <BY2PR0201MB17842502187CCC1A7AFE7090BF2C0@BY2PR0201MB1784.namprd02.prod.outlook.com>
Date: Wed, 22 Jun 2016 15:30:26 +0200
Message-ID: <CAF+90c-QmtqzJ65FzZSXmG0K1tOd4u6zt3rrHLgSOX93E2PNdA@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Nikita Popov <nikic@php.net>, Oz Gilat <oz@zend.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c07b82abf593e0535ddf063
Subject: Re: Fixing backtraces with custom get_class_name() handler
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c07b82abf593e0535ddf063
Content-Type: text/plain; charset=UTF-8

On Wed, Jun 22, 2016 at 3:14 PM, Dmitry Stogov <dmitry@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

--94eb2c07b82abf593e0535ddf063--