Den tor. 9. jan. 2020 kl. 23.30 skrev Mike Schinkel <m...@newclarity.net>: > > > Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel <m...@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.
It is not about adding a new keyword; the keyword "trait" already exists and "::trait" is a combination of an operator and an already existing keyword (since we are educating each other). 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. > 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. You cannot check that a class reuses a trait or not when it is constructed because it is compiler assisted copy/paste. They are a useless symbol to refer to in the context of ::class. I can understand you wish to make a helpful error message to a developer who fails to write a class that is loadable by your runtime, but in your example you are still refering to the trait as it was a type, which it technically isn't. > > One of my use-cases for referring to traits is to provide helpful hints in > error messages, i.e.: > > printf( '%s does not implement %s. You can easily implement that interface by > using %s', > get_class( $this ), > Interfaces\Foo::interface, > Traits\Foo::trait, > ); > > But the instanceof operator does not fulfill my requirements. I manage error > triggering during development and logging during production within the > function. Thus I can just use the implements_interface() function to handle > errors automatically when I am testing an assertion vs. using it just for > branching. > > You'll note I explicitly included a third parameter `$trigger_error = true` > in hopes people would notice, realize what I was doing and not think that I > needed to be educated on the existence of instanceof. 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. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
