# Changing the generated name for anon classes - Thread: https://externals.io/message/108408 - Original archive: https://news-web.php.net/php.internals/108408 - Started by Nikita Popov on 2020-02-06T11:21:17+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #108408 — Nikita Popov — 2020-02-06T11:21:17+00:00 URL: https://externals.io/message/108408#108408 Hi internals, Based on a suggestion by Nicolas Grekas, https://github.com/php/php-src/pull/5153 changes the generated name for anonymous classes to include the name of the parent class or first interface. So instead of just class@anonymous, you'll see something like EventHandler@anonymous in error messages, for example. There's a minor BC break here, for code checking for a "class@anonymous" prefix, which should be easy to rectify by checking for "@anonymous" instead. What do people think about doing this change? Regards, Nikita --- ## #108413 — Kingsquare.nl - Robin Speekenbrink — 2020-02-06T13:44:57+00:00 URL: https://externals.io/message/108408#108413 · In reply to: #108408 Nikita, Just to chime in here: would it be wise to add an interface instead? (this would automatically be added by the engine) so that the consumer of a generated class could *really* know based on the interface that it's a generated anonymous class instead of string type checking the classname? Relying on some interface seems te be more future proof than just changing the string to look up ;) Keep up the good work! Regards Robin Op do 6 feb. 2020 om 12:21 schreef Nikita Popov : > Hi internals, > > Based on a suggestion by Nicolas Grekas, > https://github.com/php/php-src/pull/5153 changes the generated name for > anonymous classes to include the name of the parent class or first > interface. So instead of just class@anonymous, you'll see something like > EventHandler@anonymous in error messages, for example. > > There's a minor BC break here, for code checking for a "class@anonymous" > prefix, which should be easy to rectify by checking for "@anonymous" > instead. > > What do people think about doing this change? > > Regards, > Nikita --- ## #108414 — Nikita Popov — 2020-02-06T13:54:19+00:00 URL: https://externals.io/message/108408#108414 · In reply to: #108413 On Thu, Feb 6, 2020 at 2:45 PM Kingsquare.nl - Robin Speekenbrink < robin@kingsquare.nl> wrote: > Nikita, > > Just to chime in here: would it be wise to add an interface instead? (this > would automatically be added by the engine) so that the consumer of a > generated class could *really* know based on the interface that it's a > generated anonymous class instead of string type checking the classname? > Relying on some interface seems te be more future proof than just > changing the string to look up ;) > "Being an anonymous class" is not a contract, so it should not be represented by an interface. We already have a reliable way to detect anonymous classes via isAnonymous() in reflection -- people who do string matching probably do so specifically because they are dealing with class strings, which may require special post-processing for anonymous classes (in particular, dropping everything after the "\0"). Nikita > Op do 6 feb. 2020 om 12:21 schreef Nikita Popov : > > > […] --- ## #108418 — Andrea Faulds — 2020-02-06T20:08:34+00:00 URL: https://externals.io/message/108408#108418 · In reply to: #108408 Hi, Nikita Popov wrote: > Hi internals, > > Based on a suggestion by Nicolas Grekas, > https://github.com/php/php-src/pull/5153 changes the generated name for > anonymous classes to include the name of the parent class or first > interface. So instead of just class@anonymous, you'll see something like > EventHandler@anonymous in error messages, for example. > > There's a minor BC break here, for code checking for a "class@anonymous" > prefix, which should be easy to rectify by checking for "@anonymous" > instead. > > What do people think about doing this change? > > Regards, > Nikita > Perhaps it would make sense to include the namespace used by the code which defines/instantiates the class? That might make it easier, when looking at a mysterious anonymous class using `var_dump()` deep in a big project perhaps, to find out where it came from. Andrea --- ## #108423 — Nikita Popov — 2020-02-07T13:35:46+00:00 URL: https://externals.io/message/108408#108423 > Hi, > > Nikita Popov wrote: > > […] > > Perhaps it would make sense to include the namespace used by the code > which defines/instantiates the class? That might make it easier, when > looking at a mysterious anonymous class using `var_dump()` deep in a big > project perhaps, to find out where it came from. > That would be a possible alternative. This is similar to what we do for closures. As we need the generated name to be reasonably concise, we can only do one or the other though. I don't know which one is more useful... Maybe Nicolas wants to chime in. Nikita --- ## #108424 — Nicolas Grekas — 2020-02-07T13:40:20+00:00 URL: https://externals.io/message/108408#108424 · In reply to: #108423 Le ven. 7 févr. 2020 à 14:36, Nikita Popov a écrit : > > > > […] > > That would be a possible alternative. This is similar to what we do for > closures. > > As we need the generated name to be reasonably concise, we can only do one > or the other though. I don't know which one is more useful... Maybe Nicolas > wants to chime in. > The proposed names are the most useful from my experience, take e.g. these lines, found in the same class: throw new class() implements ServerExceptionInterface {...}; [...] throw new class() implements ClientExceptionInterface {...}; The debugging experience is better mentioning ServerExceptionInterface or ClientExceptionInterface than the namespace of the surrounding class. The file + line info will fo straight to this surrounding class also, so the proposal maximizes the amount of useful info from my experience. Nicolas --- ## #108533 — Nikita Popov — 2020-02-13T10:42:30+00:00 URL: https://externals.io/message/108408#108533 · In reply to: #108423 > > > > […] > > That would be a possible alternative. This is similar to what we do for > closures. > > As we need the generated name to be reasonably concise, we can only do one > or the other though. I don't know which one is more useful... Maybe Nicolas > wants to chime in. > I've scrolled through anon class uses in popular composer packages, and that convinced me that parent/interface is probably the most useful information here. Adding the namespace prefix leaves you with something like "Amp\class@anonymous", which doesn't really tell you anything at all, while adding the interface gives you "Amp\CancellationToken@anonymous", which is fairly meaningful. Many more examples like this. Nikita --- ## #108855 — Niklas Keller — 2020-03-04T20:19:29+00:00 URL: https://externals.io/message/108408#108855 · In reply to: #108533 Hi Nikita, while we're changing the naming scheme, could we also get rid of the NUL byte, please? Binary in logs due to things like get_class really isn't that nice. Regarding checking whether something is an anonymous class, how about adding a function to check whether a class name is an anonymous class? Something like is_anonymous_class(get_class($obj)); Best, Niklas