Re: [RFC] Allow ::class on objects

About the proposal itself of allowing ($expression)::class, I'd be in favor. > > > Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel <mike@newclarity.net>: > > > > Traits are compiler assisted code copy/paste and not contracts (unlike > > interfaces), so there is no gain in having ::trait. > > It can already be referring to using ::class so it makes little sense to disallow ::trait > unless there is a different reason not to add another ::keyword. > > Traits are symbols, so it is not unreasonable that there would be a way to access it > symbolically so that the reference can be type checked. > > One of my use-cases for referring to traits is to provide helpful hints in error messages, > i.e.: > Regarding the inclusion of new keywords with similar behavior of :class: Would Interfaces\FooInterface::trait or Traits\FooTrait::interface cause a run time error? If I'm not mistaken ::class can't trigger error because it can't trigger autoload like class_exists() calls does. Currently ::class can be used to resolve any name like trim::class. IMMO it would be weird to have ::class with the current no autoload / error free behavior and then ::trait, ::function and ::interface triggering autoload and emitting some error level. And also it would be weird to have ::trait, ::function and ::interface with the same loose behavior as ::class, in that case, it seems less surprising to have just ::class everywhere instead.