Re: RFC: Trait expects interface
| From: | Rowan Tommins | Date: | Thu, 06 Jan 2022 17:11:50 +0000 |
| Subject: | Re: RFC: Trait expects interface | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-116833@lists.php.net to get a copy of this message | ||
On 6 January 2022 16:25:04 GMT, Chase Peeler <chasepeeler@gmail.com> wrote:
> I think the advantage would come within the trait. If I say the trait
>expects an interface with two methods, then the tool can act as if the
>interfaces methods exist in the trait even if they aren't explicitly
>defined. As others have pointed out, though, you can get the same behavior
>from declaring the methods not implemented in the trait as abstract.
This is where I wonder if people are talking at cross purposes.
The *only* advantage I've understood of the proposal is to save on copy and paste of abstract
methods from an interface into a trait, and everything else is just restating that in more
complicated ways. So, yes, static analysers could use the information about requiring an interface
in exactly the same way they can already use abstract method signatures, to validate the trait
itself - but that wouldn't be any *easier* for the tool, and in fact would be extra logic for
them to implement, so it seems an odd thing to bring up.
But some comments seem to be hinting at some *separate* advantage, to do with "correct
usage" of the trait, which I haven't grasped. It's possible that the mention of
static analysis relates to that in some way, and I'm just completely missing the point.
Regards,
--
Rowan Tommins
[IMSoP]