Parece que você só precisa dizer "traços" - e o holivar começará. Já começamos um por acidente algumas semanas atrás. E então decidimos descobrir. O que é mais? Uma forma de reduzir a duplicação de código. Uma maneira rápida de implementar funcionalidades. Implementação padrão da interface. Ou um antigo mal?
Considere com exemplos - esta quarta-feira à noite no YouTube . E abaixo você pode ver as posições dos participantes da transmissão.
Como será. Faremos algo próximo a um debate: uma série de rodadas, oponentes, um moderador. E votando na posição que você gosta.
Valentin Udaltsov (autor do canal Pykh ) será um adversário ferrenho dos traços. Roman Pronsky ( PHP-Digest ) - anfitrião. Bem, o resto da galera vai defender o bom nome dos traços.
Kirill Nesmeyanov, defensor do desenvolvedor na SpiralScout, membro do Comitê de Programação PHP Rússia
- O que há de errado com os traços?
- Sim, tudo é "assim" com eles: isto é uma ferramenta - use-a corretamente. Martelar pregos com um microscópio não é muita astúcia. O problema são aqueles que estão tentando empurrá-los onde não deveriam, e então eles dizem: "Bem, isso é tudo, é melhor eu ir para o front-end . "
- Por que você está interessado em falar sobre isso?
- Porque nem todo mundo entende para que gama de tarefas os traços foram inventados. Por alguma razão, geralmente são considerados um meio de fatiar fisicamente as classes. É hora de parar!
- 2 horas online podem fazer você mudar de posição?
- Não.
Sergey Zhuk, líder de equipe da Skyeng, apresentador do podcast "Between Brackets"
- O que há de errado com os traços?
- Como qualquer ferramenta, o traço deve estar no arsenal do desenvolvedor. Mas vale a pena usá-lo corretamente: por exemplo, para compartilhar alguns métodos auxiliares entre classes não relacionadas em bibliotecas, onde queremos dar aos usuários a capacidade de estender a funcionalidade sem herança ou DI.
É claro que as características podem vazar. E para não atirar no meu pé, identifiquei três regras para mim:
- Qualquer característica deve ter uma interface correspondente.
- Um traço deve ser completamente autossuficiente: tudo o que ele usa deve ser declarado dentro dele.
- As características devem ser as menores possíveis. Idealmente, um método, uma característica.
- Por que você está interessado em falar sobre isso?
- Muitos desenvolvedores são totalmente contra esse recurso do PHP. Seria interessante discutir com eles. Até agora, para mim, parece: "Eu tentei git rebase -> baguncei meu repositório -> git rebase é mau . "
- 2 horas online podem fazer você mudar de posição?
- Sim.
Ivan Leschev, desenvolvedor da BotHelp.io
- O que há de errado com os traços?
- Está tudo bem, só alguém não sabe cozinhá-los corretamente.
- Por que você está interessado em falar sobre isso?
- É interessante ver exemplos de design bom e ruim.
- 2 horas online podem fazer você mudar de posição?
- Mais provavelmente não do que sim.
Alexander Dubovskoy, CTO da Radon, membro ativo da comunidade Drupal
- O que há de errado com os traços?
- É assim. É apenas um martelo que pode ser atingido no dedo.
Holyvar vai desde pelo menos o artigo de Anthony Ferrara de 2011, Are traits the new eval . Mas então havia alguns exemplos bonitos, para os quais agora você pode acessar facilmente os componentes do Symfony. O mesmo LockableTrait é terrivelmente conveniente e compreensível (por que e por quê)
- Por que você está interessado em falar sobre isso?
- Quaisquer disputas arquitetônicas são interessantes. No mínimo, você ouvirá novos pontos de vista e descobrirá o que mais ler.
- 2 horas online podem fazer você mudar de posição?
- Não.
ps
Nikita Popov: Eu particularmente não gosto de traços. Estou envolvido no desenvolvimento desde o PHP 5.5 e eles foram adicionados no 5.4. Se eu tivesse sido naquela época, eles certamente não teriam sido adicionados.
pps Se houver uma ótima história sobre como os traços salvaram ou arruinaram a todos, compartilhe-a no stream em 23 de dezembro . E em qualquer caso - conecte-se.