Re: [RFC] Allow ::class on objects

> > Hey Marco, > > > On Jan 9, 2020, at 5:04 PM, Marcio Almada <marcio.web2@gmail.com> wrote: > > > > 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. > > You are absolutely correct. I am so used to PhpStorm highlighting issues that I sometimes > assume that PHP will throw an error/warning for the same. > > So if ::interface and ::trait were added, then (tools like) PhpStorm could have enough > information to flag them if developers misspell them or they are otherwise unknown. > > > And also it would be weird to have ::trait, > > ::function and > > ::interface with the same loose behavior as > > ::class > > Why weird? > Because we would be expanding a construct that already looks inappropriate from a purely semantic POV with aliases that also would allow inappropriate usage some_function::interface. I'd rather have a generally unsatisfying construct than a set of "denormalized" constructs with equal potential for human inaccuracy. Perhaps the problem is that ::class was not exactly a good language design decision in the first place or maybe it made more sense in the past and as the language evolved it started to appear to be named poorly. A more _general_ construct like a nameof operator, as we have in C#, could have been a brighter idea. See: - https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/nameof - https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#nameof-expressions > I can only assume Foo::trait vs. Bar::interface vs. Baz::class would not be hard to grok, and > that it would would provide more valuable information to a reader than Foo::class vs. Bar:: class > vs. Baz::class. > > > in that case, it seems less surprising to have just > > ::class > > everywhere instead. > > How so? I was very surprised when I first realized that I could do MyInterface::class, but I > would not have been surprised by MyInterface::interface. > Others could say they get more astounded with SomeTrait::function being equally valid. It's much easier to explain that ::class is general and works everywhere (even though I don't think it's good). > > ::function > > That said you bring up one I did not but would also like ::function as well as > ::method and even ::var or ::variable and ::const or ::constant. > Hahaha You're welcome :P Marcio