> 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.
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.:
printf( '%s does not implement %s. You can easily implement that interface by
using %s',
get_class( $this ),
Interfaces\Foo::interface,
Traits\Foo::trait,
);
>> use Interfaces;
>> if ( implements_interface( $object, Interfaces\MyInterface::interface,
>> $trigger_error = true )) {
>> return;
>> }
> If your $object variable is an actual instance, you can use the
> instanceof operator, it treats the right operand as a first class
> citizen and allows you to skip writing ::class:
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.
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
