On Wed, 11 Nov 2015 01:06:32, Andrea Faulds <a...@ajf.me> wrote:
This is mostly tangential, but I note that we use "{closure}" as the name
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, and
I'm keen to get this sorted out before 7.0 launches, so that we don't get
stuck with something suboptimal until 8.0 because of BC concerns.
To be honest, the original meaning of the class names has been lost since
Phil and Joe's RFC[1]. It had originally been `class@0x[addr]`, which had a
reasonable semantic interpretation of "the (otherwise anonymous) class
which
can be found at the address [addr]". Dmitry added[2] the null byte and the
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 “mine@0x7fc4be471000”.
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 anonymous
classes that is not only inconsistent with an existing feature of the
language, but has little in the way of reasoning behind its current format.
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 all
anonymous classes will show as "class@anonymous" (which I'd happily change
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=php-src.git;a=commitdiff;h=2a1b0b1#patch1
[3] http://git.php.net/?p=php-src.git;a=commitdiff;h=4a7061b#patch1
[4]
https://github.com/php/php-src/compare/master...stevenhilder:hide-anon-class-suffix
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
