Re: [RFC] Allow ::class on objects

From: 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

« previous php.internals (#108080) next »