Re: [RFC] Allow ::class on objects
| From: | Mike Schinkel | Date: | Thu, 09 Jan 2020 21:30:08 +0000 |
| Subject: | Re: [RFC] Allow ::class on objects | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-108080@lists.php.net to get a copy of this message | ||
> Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel <mike@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