Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89166
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sevenpercent.solutions designates 46.101.25.58 as permitted sender)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "PHP Internals" <internals@lists.php.net>
References: <CANUQDCh5R3dir=fzb3uGgKUrbk266BR6xWLn4Gt0-OWCOfZtAQ@mail.gmail.com> <alpine.DEB.2.20.1511091643530.14376@whisky.home.derickrethans.nl> <72.8B.21426.C9492465@pb1.pair.com>
Date: Wed, 11 Nov 2015 04:13:28 +0200
Cc: "Andrea Faulds" <ajf@ajf.me>
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
Organization: SevenPercent Solutions Ltd.
Message-ID: <op.x7wy4qw4twp9n2@charlie>
In-Reply-To: <72.8B.21426.C9492465@pb1.pair.com>
User-Agent: Opera Mail/1.0 (MacIntel)
Subject: Re: [PHP-DEV] Null bytes in anonymous class names
From: steven.hilder@sevenpercent.solutions ("Steven Hilder")

On Wed, 11 Nov 2015 01:06:32, Andrea Faulds <ajf@ajf.me> wrote:
> This is mostly tangential, but I note that we use "{closure}" as the n=
ame
> of anonymous functions. So, maybe it should be "{class}@..." for  =

> anonymous
> classes? It's at least semi-consistent...

Hi Andrea,

Only slightly tangential - I'm interested in your input on this issue, a=
nd
I'm keen to get this sorted out before 7.0 launches, so that we don't ge=
t
stuck with something suboptimal until 8.0 because of BC concerns.

To be honest, the original meaning of the class names has been lost sinc=
e
Phil and Joe's RFC[1]. It had originally been `class@0x[addr]`, which ha=
d a
reasonable semantic interpretation of "the (otherwise anonymous) class  =

which
can be found at the address [addr]". Dmitry added[2] the null byte and t=
he
filename, but he did so between the '@' and the '0x[addr]', with  =

'anonymous'
added (just for good measure?). At this point, the purpose of the  =

'@'-symbol
was gone, in my opinion.

Furthermore, the RFC allowed for the portion of the name before the '@' =
to
identify the parent class:

     class mine {}
     new class extends mine {};

     This class name will be =E2=80=9Cmine@0x7fc4be471000=E2=80=9D.

This behaviour was present in Joe's original implementation, but later
removed[3] by Nikita. His commit message says that this was "dead code",=
  =

but
I don't see what was wrong with it.

The result of all of this is that we have a naming convention for anonym=
ous
classes that is not only inconsistent with an existing feature of the
language, but has little in the way of reasoning behind its current form=
at.

My patch[4] aims to save userland from this mess by hiding the entire  =

suffix
wherever anonymous classes' names are to be displayed. This means that a=
ll
anonymous classes will show as "class@anonymous" (which I'd happily chan=
ge
to "{class}" in keeping with "{closure}") in userland, with no way of
retrieving the internal name; not even using `ReflectionClass`. My  =

reasoning
is that users should never need to know the underlying names; if a class=
  =

has
a distinct name, then it's not really *anonymous*, is it?

Kind regards,
Steve

[1] https://wiki.php.net/rfc/anonymous_classes#internal_class_naming
[2] http://git.php.net/?p=3Dphp-src.git;a=3Dcommitdiff;h=3D2a1b0b1#patch=
1
[3] http://git.php.net/?p=3Dphp-src.git;a=3Dcommitdiff;h=3D4a7061b#patch=
1
[4]  =

https://github.com/php/php-src/compare/master...stevenhilder:hide-anon-c=
lass-suffix