While I agree that traits accessing properties is an issue in terms of guaranteed interfaces and encapsulation, I'm not sure what the callable example adds to this discussion…? It does something entirely different and seems rather unrelated to clarifying the traits issue. Can you clarify?
Sure, it's simply there to show there are other, more traditional, ways to implement code reuse via collaborators. These are pretty common way of reusing a single method between classes. I'm not attempting to imply that they're the only way to do it.
If I had more than 1 method to share I wouldn't have gone with the callable strategy, and rather just used a basic class.
Hmm, I believe a better alternative would have been what you discussed in another comment: have the trait call a method on its host class to set the name, and define that method as abstract within the trait. That establishes clear interfaces and demonstrates how to use traits "safely".
Using composition which instead does nothing doesn't seem terribly useful… :)
I don't agree with this.
It's too easy for people to use traits unsafely. Sure everyone on your team might know to do that, but when a new person joins your team how do you maintain that culture.
There is also a large number of people in the PHP community generally who also don't know use them safely. That's a tough cultural fight, that I'd rather not have.
Better not to have traits in the first place, use standard composition. You don't have to fight culture, and it has no negative impact on your code.
So basically you're saying don't use traits? That's certainly one position to have. I think they can be useful in certain situations, so eschewing them entirely is maybe throwing out the baby with the bathwater. But I agree that you need to know why they can be bad if you do use them.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.