It seems that you just need to say "traits" - and the holivar will begin. We already started one by accident a couple of weeks ago. And then we decided to figure it out. What is it more? A way to reduce code duplication. A quick way to implement functionality. Default implementation of the interface. Or an ancient evil?
Consider with examples - this Wednesday night on YouTube . And below you can see the positions of the broadcast participants.
How it will be. We will arrange something close to a debate: a series of rounds, opponents, a moderator. And voting for the position you like.
Valentin Udaltsov (author of the Pykh channel ) will be an ardent opponent of traits. Roman Pronsky ( PHP-Digest ) - host. Well, the rest of the guys will defend the good name of the traits.
Kirill Nesmeyanov, developer advocate at SpiralScout, member of the PHP Russia Programming Committee
- What's wrong with the traits?
- Yes, everything is "like that" with them: this is a tool - use it correctly. Hammering nails with a microscope is not a lot of cleverness. The problem is those who are trying to shove them where they should not, and then they are like: "Oh well, that's all, I'd better go to the front-end . "
- Why are you interested in talking about this?
- Because not everyone understands for what range of tasks the traits were invented. For some reason they are usually considered a means of physically slicing up classes. It's time to stop!
- Can 2-hour online make you change your position?
- No.
Sergey Zhuk, team lead at Skyeng, host of the podcast "Between Brackets"
- What's wrong with the traits?
- Like any tool, the trait should be in the developer's arsenal. But it's worth using it correctly: for example, for sharing some helper methods between unrelated classes in libraries, where we want to give users the ability to extend functionality without inheritance or DI.
Of course, traits can become leaky. And in order not to shoot myself in the foot, I have identified three rules for myself:
- Any trait must have a corresponding interface.
- A trait must be completely self-sufficient: everything that it uses must be declared within itself.
- Traits should be as small as possible. Ideally, one method, one trait.
- Why are you interested in talking about this?
- Many developers are totally against this PHP feature. It would be interesting to argue with them. So far for me it looks like: "I tried git rebase -> messed up my repository -> git rebase is evil . "
- Can 2-hour online make you change your position?
- Yes.
Ivan Leschev, developer at BotHelp.io
- What's wrong with the traits?
- Everything is ok, just someone does not know how to cook them correctly.
- Why are you interested in talking about this?
- It's interesting to see examples of good and bad design.
- Can 2-hour online make you change your position?
- More likely no than yes.
Alexander Dubovskoy, CTO at Radon, active member of the Drupal community
- What's wrong with the traits?
- It's like that. It's just a hammer that can be hit on the finger.
Holyvar stretches from at least Anthony Ferrara's 2011 article Are traits the new eval . But then there were few beautiful examples, for which now you can easily go to Symfony components. The same LockableTrait is terribly convenient and understandable why and why)
- Why are you interested in talking about this?
- Any architectural disputes are interesting. At the very least, you will hear fresh points of view and find out what else to read.
- Will 2-hour online make you change your position?
- No.
ps
Nikita Popov: I don't particularly like traits. I am involved in development since PHP 5.5 and they were added in 5.4. If I had been then, they certainly would not have been added.
pps If there is a great story about how traits saved or spoiled everyone, please share it on the stream on December 23rd . And in any case - get connected.