> > Hey Marco, > > > On Jan 9, 2020, at 5:04 PM, Marcio Almada <marcio.w...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
