> On Jan 9, 2020, at 5:30 PM, Kalle Sommer Nielsen <ka...@php.net> wrote: > > I cannot see any benefits to adding the ::trait syntax (nor the ::interface) > one > besides some OCD issue that you are using ::class on an instance or name > of something that technically is not a class, like in your below > example, even less when ::class already is working.
The benefit is _clarity_ for when reading code. Is wanting clarity considered OCD? >> 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. > > That is where you are wrong, traits are not contracts, so therefore > they are not types. That is a distinction without a difference. And I did not say I wanted to check it for a contract. I simply wanted to reference it. > They are a useless symbol to refer to in the context of ::class. I said I wanted to refer to it when composing error message, as one example. That is not useless. Why is it so important to push back on this? What harm does having it cause when clarity is the benefit? > but in your example you are still referring to the trait as it was a type How am I referring to the trait as a type? I simply referenced it in an error message. > That is fine if the instanceof operator does not do it for you, but > you could have left that last part of the comment out of the mail, > after all, it was just a tip. I am frustrated by people constantly telling me how they think I should code when I ask for features, that people assume because they cannot envision it that a feature is problematic, and I was annoyed you assumed that as someone on this list I would need that tip. But you are right. I apologize. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
