Changing the generated name for anon classes

  108408
February 6, 2020 11:21 nikita.ppv@gmail.com (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
  108413
February 6, 2020 13:44 robin@kingsquare.nl ("Kingsquare.nl - Robin Speekenbrink")
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 ppv@gmail.com>:

> 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
February 6, 2020 13:54 nikita.ppv@gmail.com (Nikita Popov)
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 ppv@gmail.com>: > >> 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 >> >
  108418
February 6, 2020 20:08 ajf@ajf.me (Andrea Faulds)
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