Parece que solo necesitas decir "rasgos" y comenzará el holívar. Ya comenzamos uno por accidente hace un par de semanas. Y luego decidimos resolverlo. ¿Qué es más? Una forma de reducir la duplicación de código. Una forma rápida de implementar la funcionalidad. Implementación predeterminada de la interfaz. ¿O un mal antiguo?
Considere con ejemplos: este miércoles por la noche en YouTube . Y a continuación puede ver las posiciones de los participantes de la transmisión.
Cómo sera. Organizaremos algo parecido a un debate: una serie de rondas, oponentes, un moderador. Y votando por el puesto que te gusta.
Valentin Udaltsov (autor del canal Pykh ) será un ferviente oponente de los rasgos. Roman Pronsky ( PHP-Digest ): anfitrión. Bueno, el resto de los muchachos defenderán el buen nombre de los rasgos.
Kirill Nesmeyanov, promotor de desarrolladores de SpiralScout, miembro del Comité de Programación de PHP Rusia
- ¿Qué pasa con los rasgos?
- Sí, todo es "así" con ellos: esta es una herramienta - úsala correctamente. Martillar clavos con un microscopio no es mucha astucia. El problema son aquellos que están tratando de empujarlos donde no deberían, y luego dicen: "Bueno, eso es todo, será mejor que vaya al frente" .
- ¿Por qué te interesa hablar de esto?
- Porque no todo el mundo comprende para qué tipo de tareas se inventaron los rasgos. Por alguna razón, generalmente se los considera un medio para dividir físicamente las clases. ¡Es hora de parar!
- ¿2 horas en línea pueden hacerle cambiar de posición?
- No.
Sergey Zhuk, líder del equipo en Skyeng, presentador del podcast "Between Brackets"
- ¿Qué pasa con los rasgos?
- Como cualquier herramienta, el rasgo debe estar en el arsenal del desarrollador. Pero vale la pena usarlo correctamente: por ejemplo, para compartir algunos métodos auxiliares entre clases no relacionadas en bibliotecas, donde queremos brindar a los usuarios la capacidad de extender la funcionalidad sin herencia o DI.
Por supuesto, los rasgos pueden tener fugas. Y para no dispararme en el pie, he identificado tres reglas para mí:
- Cualquier rasgo debe tener una interfaz correspondiente.
- Un rasgo debe ser completamente autosuficiente: todo lo que utiliza debe declararse en sí mismo.
- Los rasgos deben ser lo más pequeños posible. Idealmente, un método, un rasgo.
- ¿Por qué te interesa hablar de esto?
- Muchos desarrolladores están totalmente en contra de esta función de PHP. Sería interesante discutir con ellos. Hasta ahora, para mí parece: "Probé git rebase -> arruiné mi repositorio -> git rebase is evil" .
- ¿2 horas en línea pueden hacerle cambiar de posición?
- Si.
Ivan Leschev, desarrollador de BotHelp.io
- ¿Qué pasa con los rasgos?
- Todo está bien, solo alguien no sabe cocinarlos correctamente.
- ¿Por qué te interesa hablar de esto?
- Es interesante ver ejemplos de buenos y malos diseños.
- ¿2 horas en línea pueden hacerle cambiar de posición?
- Más probablemente no que sí.
Alexander Dubovskoy, director de tecnología de Radon, miembro activo de la comunidad Drupal
- ¿Qué pasa con los rasgos?
- Es así. Es solo un martillo que puedes golpear con el dedo.
Holyvar se extiende desde al menos el artículo de 2011 de Anthony Ferrara Are traits the new eval . Pero luego hubo algunos ejemplos hermosos, para los cuales ahora puede ir fácilmente a los componentes de Symfony. El mismo LockableTrait es terriblemente conveniente y comprensible por qué y por qué)
- ¿Por qué estás interesado en hablar de esto?
- Cualquier disputa arquitectónica es interesante. Como mínimo, escuchará nuevos puntos de vista y descubrirá qué más leer.
- ¿2 horas en línea pueden hacerle cambiar de posición?
- No.
PD
Nikita Popov: No me gustan especialmente los rasgos. Estoy involucrado en el desarrollo desde PHP 5.5 y se agregaron en 5.4. Si lo hubiera sido entonces, ciertamente no se habrían agregado.
pps Si hay una gran historia sobre cómo los rasgos salvaron o estropearon a todos, compártala en las novedades el 23 de diciembre . Y en cualquier caso, conéctese.