Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89172
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <op.x7wnlatwtwp9n2@charlie>
References: <CANUQDCh5R3dir=fzb3uGgKUrbk266BR6xWLn4Gt0-OWCOfZtAQ@mail.gmail.com>
	<563B6ED1.1030601@gmail.com>
	<CAPwsocG6yU0sKYLaT4DM-KA1HTf6rLr=kn7G88GeduqK7pASGg@mail.gmail.com>
	<CANUQDChkBEwvHq+8d1UU0d7pKy0MgTcfY38dsCQ898CF86_B6Q@mail.gmail.com>
	<op.x7uajofhtwp9n2@charlie>
	<CAPwsocEpk2Ygz48-0Gn5KeChfCj+kacJodU9PKRmxFjmdNQcYg@mail.gmail.com>
	<op.x7wnlatwtwp9n2@charlie>
Date: Wed, 11 Nov 2015 11:01:15 +0100
Message-ID: <CAF+90c8AaK3XQyFD+dsN6G5eyh0g7oGhLCctdqRVoTaFCr0hfw@mail.gmail.com>
To: Steven Hilder <steven.hilder@sevenpercent.solutions>
Cc: PHP Internals <internals@lists.php.net>, Leigh <leight@gmail.com>, 
	Derick Rethans <derick@php.net>, Niklas Keller <me@kelunik.com>, Rowan Collins <rowan.collins@gmail.com>, 
	Joe Watkins <krakjoe@php.net>, Dmitry Stogov <dmitry@zend.com>
Content-Type: multipart/alternative; boundary=047d7ba973ce334680052440e873
Subject: Re: [PHP-DEV] Null bytes in anonymous class names
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7ba973ce334680052440e873
Content-Type: text/plain; charset=UTF-8

On Tue, Nov 10, 2015 at 11:04 PM, Steven Hilder <
steven.hilder@sevenpercent.solutions> wrote:

On Mon, 09 Nov 2015 16:48:57, Leigh <leight@gmail.com> wrote:
>
>> On 9 November 2015 at 15:27, Steven Hilder
>> Can you share your patch?
>>
>
> See
> https://github.com/php/php-src/compare/master...stevenhilder:hide-anon-class-suffix
>
> Feedback very welcome :)
>
> It should be possible to return the sanitised name without removing it
>> internally.(would have to cover the get_parent_class and getParentClass
>> versions too, and have a quick audit of other places class names can be
>> spat out.)
>>
>
> Yes, that's what I had in mind. The class names are sanitised only for
> display in userland; I haven't changed the way that the names are generated
> or stored internally.
>
> I've applied the change to `get_parent_class()` and `get_called_class()`.
> Nothing needed to be done for `ReflectionClass::getParentClass()` because
> it
> returns another `ReflectionClass` object, not the parent's name.
>
> The `__CLASS__` magic constant and `::class` syntax also needed changes.
> The
> patch includes a test which shows all of the scenarios that I've accounted
> for. Please do let me know if you can think of any others.
>
> I've also implemented the change to `class_alias()` as I described in my
> previous email.
>

I'd like to clarify some things here from the perspective of the people who
implemented this naming scheme.

The naming was chosen to be this way intentionally, to combine two
behaviors we would like to have:

a) Things like get_class() MUST return a class name that uniquely
identifies the anonymous class. You should be able to instantiate a new
instance of the same class based on it, etc. Having these return truncated
names is an absolute no-go, because it would require people to explicitly
handle anonymous classes in many context that currently "just work".

b) We do not want to display the fully mangled name of an anonymous class
in error messages or debug dumps. While the information contained there can
be useful, it also significantly bloats outputs. Furthermore we will likely
change the exact naming structure in the future, in which case the
anonymous class name will no longer contain any directly useful information
(maybe some hash).

Using a NUL byte conveniently achieves both of these goals. We did not
however take into account that this would cause issues with 3rd party
tooling that does not support binary data.

As such, we may have to change the naming. However we must retain goal a)
and would like to retain b). To do this we could use names along the lines
of class@anonymous$1, where the uniquely-identifying information is short
enough to be no bother when displayed. Generating these kinds of names is
non-trivial if you consider caching and may require some changes to the way
we perform class bindings. (As a side bonus, depending on how this is done,
we might fix https://bugs.php.net/bug.php?id=64291 as well.)

Not sure if this is still in scope for PHP 7.0.

Nikita

--047d7ba973ce334680052440e873--