On Thu, Jan 6, 2022 at 12:37 PM Alexandru Pătrănescu <dreal...@gmail.com> wrote:
> On Thu, Jan 6, 2022 at 7:12 PM Rowan Tommins <rowan.coll...@gmail.com> > wrote: > > > > > 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. > > > > Yes, traits are a language construct that has in general more negative > implications than positive so it's good to keep an eye on their usage. > One of the okish usages is to define some implementation for an interface > that classes can use. > Limiting that trait to be used only by classes implementing the interface > is seen as a restriction placed on the trait that would not allow it to be > used in other places when it might have a negative impact. > > And that's what I don't like about this. I'm totally OK with allowing developers to do things the "wrong" way. It might end up that it's the "right" way for their use-case. > Just as a note, on the composition vs inheritance line, I see traits > somewhere in the middle. > I'll always prefer to go for full composition, even if that means a bit > more boilerplate. The implementation can very well sit in a class and have > it as a dependency of the class that needs it. > > Alex > > 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. I think most people see the tools as black boxes to make THEIR lives easier. They aren't concerned about whether it's added complexity to the tool itself. If PhpStorm allows me to reference $this->someMethodFromAnInterface() without defining someMethodFromAnInterface() as an abstract method in the trait because I include "expects <interface>", then that means things are "simpler" for me as a developer. I don't really think this makes things that much simpler though. -- Chase Peeler chasepee...@gmail.com
